[ https://issues.apache.org/jira/browse/JCLOUDS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15826707#comment-15826707 ]
Ignasi Barrera commented on JCLOUDS-1225: ----------------------------------------- {quote} Are you suggesting not doing anything, which essentially means people will not be able to use both jclouds and Guava 21 in their project? {quote} Yes, I'm suggesting that, but there is no need to fork or change the jclouds code, and it does not mean people won't be able to use jclouds. I was just suggesting that, instead of making jclouds eagerly shade its dependencies, it makes more sense that projects that have dependency conflicts, shade their jclouds dependency. As a practical example you can copy, the [Jenkins jclouds-plugin|https://github.com/jenkinsci/jclouds-plugin] does this. It just requires to create a [simple pom.xml file|https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-shaded/pom.xml] that contains the jclouds dependencies, and [configures the maven-shade-plugin|https://github.com/jenkinsci/jclouds-plugin/blob/master/pom.xml#L144-L184] to create a jclouds shaded jar that contains all jclouds and Guava classes. Then the project just needs to depend [on the jclouds shaded jar|https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/pom.xml#L70-L74]. I strongly encourage you to follow this approach instead of keeping a fork with such substantial changes to jclouds. This is simple and clean, does not require hacks in jclouds nor require forking, and can be used by projects to fix any existing dependency conflict in a clean way, without propagating environment specific issues to the different libraries used by the project. > Guava 21 compatibility > ---------------------- > > Key: JCLOUDS-1225 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1225 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core > Affects Versions: 2.0.0 > Reporter: Ian Springer > Labels: guava > > The below classes use com.google.common.base.Objects.ToStringHelper, which > has been deprecated since Guava 18, and has been removed in Guava 21. This > makes it impossible to use jclouds in a project using Guava 21. Please either > upgrade to Guava 18+ and switch to using > com.google.common.base.MoreObjects.ToStringHelper, or drop the usage of > ToStringHelper altogether. This will allow my project to upgrade to Guava 21 > without having to use a fork of jclouds. > * org/jclouds/apis/internal/BaseApiMetadata.java > * org/jclouds/domain/internal/LocationImpl.java > * org/jclouds/domain/internal/MutableResourceMetadataImpl.java > * org/jclouds/domain/internal/ResourceMetadataImpl.java > * org/jclouds/http/HttpMessage.java > * org/jclouds/http/HttpRequest.java > * org/jclouds/http/HttpResponse.java > * org/jclouds/internal/BaseView.java > * org/jclouds/providers/internal/BaseProviderMetadata.java > * org/jclouds/reflect/InvocationSuccess.java > * org/jclouds/rest/internal/BaseHttpApiMetadata.java > * org/jclouds/rest/suppliers/URIFromStringSupplier.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)