datastax
Rethink Guava dependency in Java driver
So, I think this is fine as it stands, and it appears to accomplish the goal we want but I can't help but wonder... do we really even need this JAR anymore? Is there a clear argument for including this shaded JAR vs. just including (as a shaded JAR or as a stated dependency) Guava directly?
The above may be a dumb question; it's quite possible there's some aspect of this I'm not seeing. But as I look through this code I can't help but think that we're going to a lot of trouble to create a dependency from a shaded Guava JAR which seems... like something we could do without all that trouble.
Based on conversation in ASF Slack it sounds like this might be moving in the direction of adding Guava to core-shaded and just making Guava a straight dependency for the non-shaded build. This creates two very distinct configurations: one with zero shading (the core JAR) and one with multiple major dependencies shaded (core-shaded). If users experience conflicts with the Guava version in use in their application and what the Java driver needs we can recommend those users move to core-shaded.
The analysis above is not settled yet, however, so this could still change.
Declared Guava as a dependency to core module. Changes pushed.
@absurdfarce, @adutra: I still have a problem with OsgiShadedIT. Our OSGi test project (src/main/java/com/datastax/oss/driver/api/osgi) uses mapper and query builder. Those two modules do not have shaded versions and they depend on Guava (mapper runtime could skip Guava dependency, but inside query builder it is more widely used). Previously they both included shaded Guava as a dependency. I could not remove Guava bundle from OsgiShadedIT. Tested locally that when I remove all dependencies for mapper runtime and query builder from test project, shaded core driver does not require Guava. I have tried to implement a new test and use Pax Exam to create OSGi bundle from only part of test project (include only classes that do not import com.datastax.oss.driver.api.mapper), but not sure if it is possible. We could create a test like this with completely new Maven module, but not sure if it is worth the effort. What is you view on the issue?
I ended up implementing TweetService that does not use mapper and query builder. BundleOptions.applicationCoreBundle() creates also a small OSGi bundle with just Tweet service and its dependencies (skipping MailboxService and its imports). Test infrastructure is brought by BundleOptions.testBundles() and it also uses Guava. I have refactored parts of test-infra classes not to use Guava internally.
I am changing the title of this PR to later rethink handling he dependency of Guava in the Java driver. All details have been captured in CASSJAVA-62. Let us wait with this PR until we are allowed to do a potentially breaking change. This PR includes some valuable work to use Guava as standard dependency (mainly one OSGi test).