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.