Proposal to minimize Dependency Conflicts

[lesv]

Many customers are running into dependency conflicts using the Java google-cloud (an umbrella package that includes many other artifacts), several of our google-cloud-* artifacts together, and using the google-cloud-* artifacts with other non google-cloud, google artifacts like GoogleCloudPlatform/google-cloud-datastore . This leads to the Maven Dependency issues.

The common java solution of creating a BOM (SpringBoot) (SpringBoot Gradle) and using the maven-enforcer-plugin doesn't work when there are artifacts that aren't well behaved (same JAR, but substantially different method signatures and behaviors) like Netty (See #2398 ) included in the mix. Our customers are running into situations where they are combining our artifacts with those of slower moving open source projects and things are breaking in very unexpected ways.

Additionally, customers appear to be confused by google-cloud as it's marked as alpha, even though it brings in some "GA" artifacts.

@ludoch has proposed (and I agree):

1. We have three Uber JAR's that we release GA, BETA, and ALPHA (Beta & Alpha can depend on GA)
2. We shade w/ illegal class names so that IDE's will not auto complete.
3. We then run ProGuard to shrink these JAR's.
4. The individual product JAR's should also be done this way.
5. We should still publish non-shaded / non-ProGuarded artifacts for those who need them.

Drawbacks

1. Larger JAR's
   Better reliability will more than offset the issues with additional size.
2. Singleton's are no longer pure. (ie some resources might not be properly guarded)
   We should be able to figure this out for libraries.
3. Debugging becomes harder
   (We should publish enough info to figure this out)

Benefits

1. We will only expose our public Classes and Methods. Our dependencies stay out of the mix.
2. Less customer confusion.

Of course, all we are doing is trying to solve a problem that Java 9 modules also attempts to solve, but our JAR's can't wait for our customers to all get to Java 9.

[lesv]

@ludoch @jabubake FYI

[janedegtiareva]

Do we know how much larger the JARs will become? Also it would be good to have more details about the extra debugging complexity. Thank you!

[lesv]

The total size would be less than you current use (that's one of the gifts of Proguard), but if your app includes the same jar, it will be there twice. This is only for an additional kind of jar that we publish, so you would still be able to use the current jar's.

For debugging, this will be similar to what users do on android debugging.

[yihanzhen]

Move this issue to feature request backlog and close it here. This place can still be used for discussion.

[garrettjonesgoogle]

There is a potential for this creating new problems, and maybe even more problems than it solves. If a user somehow includes a package from anywhere that pulls in one of the jars from the non-uber-jarred version, there will be version problems, similar to the guava vs guava_jdk5 nightmare we have right now. Types from the following packages (at a minimum) are exposed on the surface of google-cloud-java and can't be hidden away:

• api-common-java
• proto-cloud-*
• grpc-cloud-*
• gax-java
• google-cloud-core*