[
https://issues.apache.org/jira/browse/STORM-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120479#comment-14120479
]
ASF GitHub Bot commented on STORM-447:
--------------------------------------
Github user ptgoetz commented on the pull request:
https://github.com/apache/incubator-storm/pull/219#issuecomment-54369457
@revans2 I just did a bunch of digging related to how the shade plugin
handles dependencies. When a shaded artifact is installed or deployed to a
maven repository, it is installed with the `dependency-reduced-pom.xml` instead
of the original `pom.xml` it was built with. You have the choice of either
removing shaded dependencies from the pom, or have them set to `provided` scope.
Currently, our build is configured to set them to `provided` scope, which
is actually not what we want, so we need to make the following change to the
storm-core pom (which I've already done, just haven't pull requested it yet):
```
<keepDependenciesWithProvidedScope>false</keepDependenciesWithProvidedScope>
```
When maven builds a jar, it also puts the pom in
`META-INF/${groupId}/${artifactId}/pom.xml`. In a shaded jar this will be the
original pom, not the dependency reduced one. I'm not aware of any tools that
use that pom, most use the pom that's in the maven repository. However, I do
have a patched version of the shade plugin that will use the dependency reduced
pom instead of the original if we need it.
So long story short we should be able to flip that bit and avoid the
scenarios you describe.
> shade/relocate packages of dependencies that are common causes of dependency
> conflicts
> --------------------------------------------------------------------------------------
>
> Key: STORM-447
> URL: https://issues.apache.org/jira/browse/STORM-447
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Reporter: P. Taylor Goetz
> Assignee: P. Taylor Goetz
> Fix For: 0.9.3-incubating
>
>
> A number of Storm's dependencies regularly conflict with user dependencies:
> * Netty (tends to conflict with Cassandra and others)
> * Guava
> * httpclient
> Shading these into storm-core.jar and doing package relocation will eliminate
> dependency conflicts when user code (topologies) depends on conflicting
> versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)