[
https://issues.apache.org/jira/browse/JCLOUDS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15856410#comment-15856410
]
Ian Springer commented on JCLOUDS-1225:
---------------------------------------
[~tpeierls], +1.
I just spent 3 hours trying to go the self-shaded jclouds route, and hit the
following issues along the way:
1. A complicated shade plugin config was necessary in order to pull jclouds and
its deps in, but not other things like JDK classes...
{code}
<plugin>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<id>shade</id>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
<configuration>
<relocations>
<relocation>
<shadedPattern>shaded.jclouds.</shadedPattern>
<excludes>
<exclude>META-INF/**</exclude>
<exclude>java.**</exclude>
<exclude>javax.**</exclude>
<exclude>org.slf4j.**</exclude>
<exclude>com.google.inject.**</exclude>
<exclude>org.jclouds.**</exclude>
</excludes>
</relocation>
</relocations>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
/>
</transformers>
<promoteTransitiveDependencies>true</promoteTransitiveDependencies>
<!-- TODO: Uncomment the below line once
https://issues.apache.org/jira/browse/MSHADE-248 has been fixed. -->
<!--<createSourcesJar>true</createSourcesJar>-->
</configuration>
</plugin>
{code}
2. The 5 or 6 jclouds deps that various modules in my project depend on all had
to be moved to the new jclouds-shaded module, rather than being explicitly
declared in the modules depending on them.
3. In modules depending on the new jclouds-shaded jar, I had to do the
following hack in order to prevent the original jclouds jars and their
transitive deps from getting pulled into the reactor:
{code}
<dependency>
<groupId>com.evergage.infrastructure</groupId>
<artifactId>jclouds-shaded</artifactId>
<version>${jclouds.version}</version>
<!-- jclouds relocated transitive deps are bundled in the shaded jar, so
exclude all transitive deps to
avoid pulling in the original packages -->
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
4. I had to exclude the jclouds-shaded module from the reactor, otherwise it
broke IntelliJ, because it doesn't support processing shade config relocations:
{code}
<modules>
<!-- NOTE: The below module must be excluded from the Maven reactor,
otherwise IntelliJ will get confused
(see https://youtrack.jetbrains.com/issue/IDEA-126596). -->
<!--<module>jclouds-shaded</module>-->
{code}
And after all that, I get the following exception at runtime:
{code}
Caused by: java.util.ServiceConfigurationError:
org.jclouds.providers.ProviderMetadata: Provider
shaded.jclouds.orgshaded.jclouds..shaded.jclouds.jcloudsshaded.jclouds..shaded.jclouds.gogridshaded.jclouds..shaded.jclouds.GoGridProviderMetadatashaded.jclouds.
not found
at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[na:1.8.0_121]
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
~[na:1.8.0_121]
at
java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:372)
~[na:1.8.0_121]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
~[na:1.8.0_121]
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
~[na:1.8.0_121]
at
shaded.jclouds.com.google.common.collect.ImmutableCollection$Builder.addAll(ImmutableCollection.java:281)
~[jclouds-shaded-2.0.0.jar:2.0.0]
at
shaded.jclouds.com.google.common.collect.ImmutableCollection$ArrayBasedBuilder.addAll(ImmutableCollection.java:360)
~[jclouds-shaded-2.0.0.jar:2.0.0]
at
shaded.jclouds.com.google.common.collect.ImmutableSet$Builder.addAll(ImmutableSet.java:508)
~[jclouds-shaded-2.0.0.jar:2.0.0]
at org.jclouds.providers.Providers.all(Providers.java:83)
~[jclouds-shaded-2.0.0.jar:2.0.0]
at org.jclouds.providers.Providers.withId(Providers.java:99)
~[jclouds-shaded-2.0.0.jar:2.0.0]
at org.jclouds.ContextBuilder.newBuilder(ContextBuilder.java:167)
~[jclouds-shaded-2.0.0.jar:2.0.0]
... 49 common frames omitted
{code}
At this point, I've already wasted way too much time on this, so I'll be going
back to my forked jclouds solution, which also took 3 hours, but at least it
was working, and did not introduce lots of ugly complexity to my project's
build.
I would strongly not recommend the shading route to anyone looking to use
jclouds and Guava 21 in the same 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.15#6346)
