Feature Request: Bundle Sources in Maven SDK Distribution

[JvmName]

What feature would you like to see?

First off, I think it's awesome that the Firebase SDK is being open-sourced. However, as an Android developer, my primary use-case for open source is being able to explore the sources from inside Android Studio.
Thus, I think it'd be even more awesome if y'all should ship the sources as part of the Maven bundle that we request through Gradle.

[poetrydemon1982]

i totally agree it would be better in a bundle,

[bjornick]

This sounds like a great idea. I have one question. Since our SDKs are proguarded, would this still have value if source names (and possibly code) don't have a 1:1 mapping with the classes we produce?

[JvmName]

Well, my first thought on this is: don't minify the SDK! The cat's already out of the bag, given that we're discussing this on GH! 😄

However, since I get that large orgs move slowly, having un-minified sources bundled with minified binaries is fine as a stopgap.

[bjornick]

The TL;DR of the next bit is, I am trying to get buy in to stop proguarding the open source SDKs this week. If I can, I'll make both changes by the next time we release these SDKs.

Just as an update, I'm trying to get buy-in to stop proguarding our open source SDKs.
For context, there are two reasons why we proguard the Firebase SDKs:

• obfuscation: Some SDKs want to keep their internals hidden, but obvious that doesn't apply to any of the open source sdks.
• Size impact: As a part of google, we have a vested interest in the android ecosystem, so we should do things that improve the ecosystem. Since most apps aren't proguarded and a lot of apps use some parts of Firebase, we should at least proguard our SDKs to reduce the download and install size of our SDK code. This is relevant for our open source SDKs, but I suspect that the net impact on the ecosystem is actually pretty small. I suspect that most of the top apps proguard anyway (because in many countries where data is expensive, this has a huge impact on how many installs an app gets).We are trying to get some data to figure out the size impact of not proguarding our SDKs. I think there is a decent chance that I can make some headway on this by the end of the week.

[JvmName]

Totally makes sense!

RE size impact, what if you offered two binaries: minified and un-minified?
You could publish, for example, two assets:

• 'com.google.firebase:firebase-firestore-expanded:x.x.x'for those of us who proguard already.
• 'com.google.firebase:firebase-firestore:x.x.x' is minified, keeping it backwards-compatible with the philistines users who don't yet proguard.

Thoughts?

[samtstern]

@ParthPadg we've thought about that too, but that would create confusion and probably end up with a lot of people just shipping expanded libs in their release app because they debugged with them.

As @bjornick said we are making real progress towards removing proguard from at least some of the SDKs. In my personal opinion once we remove it in a few places and world civilization fails to collapse, we'll have much more momentum to do it more broadly.

[bjornick]

Good news, we'll stop proguarding our open source SDKs. Would you still want the source jars there as well? If so, I'll track the removal of proguard in a separate issue.

[JvmName]

I'll admit a bit of ignorance RE difference between source JARs versus a non-minified binary...does one have javadocs + comments out-of-the-box?
Because then I would prefer that option 😄

[nbransby]

When can we expect the non-proguarded version to land?

Also the README mentions this repository does not contain all the source for SDK. What's missing and why?

[samtstern]

@nbransby

1. The next release will be non-proguarded.
2. As you can see, this repository only contains some of our SDKs (Firestore, Database, Storage, etc). However many Firebase SDKs like Auth, Analytics, etc are not here yet. That's what the note is saying. This is important because some of the SDKs that are open source depend on some of the closed-source ones, so you can't yet be open-source all the way down.

[samtstern]

An update here: you can now use "Go to definition" in Android Studio to see source code for all of our open-source SDKs:

However you'll notice that this Java view is produced by Android Studio on the fly by decompiling the .class bytecode files.

If we were to ship source JARs, Android Studio (and other tools) would have access to the original .java source files not just the .class files which can be decompiled.

The question is: is there much more value to this than what we have now?

[JvmName]

It's an awesome start! But the Android Studio tooling is not as string with decompiled sources as it is with actual sources -- things like Find Usage Of don't work as well.

It's definitely not a blocker, but the point of shipping un-minified is to aid in developer understanding...so this seems like the logical next step.

[matejdro]

In my opinion, including original java sources brings a lot of value:

• It enables IDE to display javadocs directly. This saves a lot of trouble of having to go to the reference page every time
• It displays detailed deprecation warnings. If method is deprecated, IDE shows it crossed out, but without original java files we can only see the @Deprecated annotation without any explanation. Again, saves the trip to the reference page

[vkryachko]

Hey folks, great news.

All releases of our open-source SDKs going forward will contain sources.jar. The first one to come out is firestore and firestore-ktx in the coming days.