This issue finally irritated me enough to go with option 1 and hack around with sed:
https://github.com/jclouds/jclouds/pull/1131 This allowed me to use Guava 23 with S3Proxy. Testing jclouds itself with Guava 21+ revealed breakage with Java 8 but this does not impact our users. I discovered google-java-format[1] which helped with some of the import changes. This has similarities to gofmt although it uses a substantially different coding style than ours. [1] https://github.com/google/google-java-format On Mon, Jul 03, 2017 at 06:06:06PM -0700, Andrew Gaul wrote: > Three months have passed so I guess we chose option 0. While this issue > concerns me and prefer options 1 or 2, I do not plan to work on this and > encourage someone to step forward with a pull request or suggest another > approach. > > On Thu, Mar 30, 2017 at 10:11:56PM -0700, Andrew Gaul wrote: > > I want to raise the profile of JCLOUDS-1225[1], Guava 21 compatibility, > > which has troubled several users recently. jclouds uses Guava 16 and > > has compatibility with Guava 16-20. Guava 21 API changes make it > > incompatible with jclouds. We have several plausible solutions: > > > > 0) Ignore the issue > > 1) Move to Guava 18 and have compatibility with Guava 18-21 > > 2) Use reflection or other workarounds to conditionally call newer > > Guava APIs > > 3) Provide some kind of shaded solution to avoid application > > incompatibilities > > > > I loathe to touch the third rail of dependency versioning given the > > history of strong opinions and a reversion which addressed this very > > issue some years back. How can we move forward here? 0 and 1 cause > > user issues while 2 and 3 pollute our code with hacks. > > > > [1] https://issues.apache.org/jira/browse/JCLOUDS-1225 > > > > -- > > Andrew Gaul > > http://gaul.org/ > > -- > Andrew Gaul > http://gaul.org/ -- Andrew Gaul http://gaul.org/
