[ 
https://issues.apache.org/jira/browse/JCLOUDS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16439474#comment-16439474
 ] 

Adrian Woodhead commented on JCLOUDS-1225:
------------------------------------------

I see this ticket has been closed but the underlying issue that the usage of 
Guava causes problems downstream is still here. We're actually having the 
opposite problem to what is described above - we're using a version of Hadoop 
which requires an *older* version of Guava (16) but because we're using S3Proxy 
in the same project, which in turn depends on JClouds, we're getting Guava 18 
pulled in and this means our code doesn't run due to backwards incompatible 
changes in Guava. I see the arguments above about not wanting to shade and 
relocate Guava but for situations like this I can't really see a better 
solution. Not doing this really does limit the uptake of JClouds and makes it a 
pain to use downstream. I've made the same point in Hadoop, downstream users 
shouldn't care what versions of libraries they are using internally. Hadoop 
should have more scope to solve this by coming up with a proper runtime 
classpath isolation scheme so dependencies like this don't leak out but I don't 
think that applies here.

> 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
>            Assignee: Andrew Gaul
>            Priority: Major
>              Labels: guava
>             Fix For: 2.1.0
>
>
> 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
(v7.6.3#76005)

Reply via email to