[
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)
