[
https://issues.apache.org/jira/browse/STORM-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14115458#comment-14115458
]
ASF GitHub Bot commented on STORM-447:
--------------------------------------
Github user revans2 commented on the pull request:
https://github.com/apache/incubator-storm/pull/219#issuecomment-53901704
OK So when you package a jar for storm we use the assembly plugin to pull
in all dependencies that the jar has, except for the dependencies that are
marked as provided, aka storm and its transitive dependencies. When we shade
one of our dependencies like guava we are no longer packaging guava with storm,
but maven still thinks that we are because our pom.xml still say that we have a
dependency on it. As such anyone who actually wants to use guava might compile
just fine, but end up with a class not found error when they try to run,
because maven was not smart enough to package guava with their jar, because it
still thinks storm is packaging it.
> 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.2#6252)
