+1 We almost didn't make the upgrade to 1.8 We changed to 1.8 code and used Andrew.G patch to downgrade guava to 16 ...
On Friday, October 24, 2014, Matt Stephenson <matts...@apache.org> wrote: > +1 > > We shaded in guava for the appengine SDK, to try to get around this, which > lead to other problems... > > Matt > On Oct 24, 2014 12:49 PM, "Adrian Cole" <adrian.f.c...@gmail.com > <javascript:;>> wrote: > > > Hi, team. > > > > I feel the need to reiterate something, which may not impact everyone, > but > > should be taken into consideration nevertheless. > > > > jclouds is best a part of a platform. As a library, it needs to take care > > not to make that impossible. Unlike some of our dayjobs, we cannot treat > > jclouds as a monorepo or a monoculture, where we can assert a particular > > version makes sense for us, then switch immediately to it. > > > > The idea of being runtime portable is a part of our legacy and played a > > part in the large adoption jclouds had prior to entering the ASF. > > > > We've drifted from there. We moved to guava 17 in jclouds 1.8 without > > analyzing the impact on our ecosystem. Core tools like jenkins weren't > > consulted and may not work at all now. I'm willing to bet that many of > the > > apps > > that use jclouds <https://jclouds.apache.org/community/users/> either > > can't > > work or were forced into a guava upgrade solely because we made them. > > > > Other platforms and potential integrations are even more difficult now. > > For example, jclouds 1.8 is now incompatible with platforms from the > last 3 > > companies I've worked at: Netflix, Square, and Twitter. While the ceiling > > version is 16.0.1 across the three, there are some in the 14 range, and a > > couple projects at 11! > > > > I asking, if not begging, to please not forget the legacy which in part > led > > us to where we are today. Please consider greatly the impact of runtime > > portability. > > > > If guava makes jclouds impossible, jclouds is impossible. Please don't > > force guava versions without thinking it through and asking diverse > users, > > or at least doing an industry poll on what is sustainable. It is really > > burdensome to backport or revert this stuff, and we all have more > important > > work to do. > > > > In summary, we want to be known for making cloud easy, not making > > dependency conflicts the norm. > > > > -A > > >
