[
https://issues.apache.org/jira/browse/STORM-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286754#comment-15286754
]
Robert Joseph Evans commented on STORM-1599:
--------------------------------------------
No it will not. Maven does a breadth first search in resolving dependencies.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Specifically it says
{quote}
* Dependency mediation - this determines what version of a dependency will
be used when multiple versions of an artifact are encountered. Currently, Maven
2.0 only supports using the "nearest definition" which means that it will use
the version of the closest dependency to your project in the tree of
dependencies. You can always guarantee a version by declaring it explicitly in
your project's POM. Note that if two dependency versions are at the same depth
in the dependency tree, until Maven 2.0.8 it was not defined which one would
win, but since Maven 2.0.9 it's the order in the declaration that counts: the
first declaration wins.
** "nearest definition" means that the version used will be the closest one
to your project in the tree of dependencies, eg. if dependencies for A, B, and
C are defined as A -> B -> C -> D 2.0 and A -> E -> D 1.0, then D 1.0 will be
used when building A because the path from A to D through E is shorter. You
could explicitly add a dependency to D 2.0 in A to force the use of D 2.0
{quote}
So all a user needs to do if they want a different version of kafka is to
include that version of kafka in the pom.xml. Just like they are doing now,
but after this change it will be optional for them to do it.
> Kafka dependencies all marked as provided (so storm-starter does not run)
> -------------------------------------------------------------------------
>
> Key: STORM-1599
> URL: https://issues.apache.org/jira/browse/STORM-1599
> Project: Apache Storm
> Issue Type: Bug
> Components: examples, Flux, storm-kafka
> Affects Versions: 0.10.0, 1.0.0, 2.0.0
> Reporter: Robert Joseph Evans
> Assignee: Hugo Louro
>
> When we mark a dependency as provided it indicates the shade and assembly
> plugins to not include this particular dependency in the uber topology jar
> because it will be {provided} on the class path by the system.
> We have been doing this for all of our kafka dependencies incorrectly. This
> means that storm-starter does not have any version of kafka packaged it the
> resulting jar and any example that uses kafka, TridentKafkaWordCount, will
> fail with missing class errors.
> storm-starter/pom.xml has should change its dependency on storm-kafka to be
> compile, and it should delete dependencies on kafka and kafka-clients as
> those should come from storm-kafka as transitive dependencies.
> the main pom.xml should not have kafka-clients marked as provided in the
> dependency management section.
> storm-kafka should remove its provided tag on kafka, and flux examples +
> storm-sql-kafka should remove dependencies on kafka and kafka-clients, and
> storm-kafka should not me marked as provided.
> the flux and sql code I am not as familiar with, but looking at them, and
> running `mvn dependecy:tree` and `mvn dependency:analyze` it looks like
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
