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
