The managing of Child A doesn't necessarily mean that Child A's
dependencies are weighed higher than other direct dependencies. Also,
given the same depth in the tree, the first version processed for a
given group:artifact wins...ie the order in the pom can have subtle
impacts.
On Mon, Sep 28, 200
Jason,
I just had one of those light bulb moments that only happens after hitting
the send button. :-)
Here is what I read at
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html:
>> *"Dependency mediation* - this determines what version of a dependency
will be u
Make a test project to express the problem. In almost all cases it's
impossible to debug or discuss this without a test project everyone
can run.
Unfortunately you can't rely 100% on the output of particular plugins
wrt dependency resolution because they can all change the output with
dif
I have a project structure like this:
Parent A
* Declares managed dependency org.slf4j:slf4j-api:1.5.8
* Declares managed dependency org.hibernate:hibernate-core:3.3.1.GA
* Declares managed dependency org.hibernate:hibernate-annotations:3.4.0.GA
Child A
* Depends on org.hibernate:hibernate
Here, in my view are some of the issues we face going forwards:
1. There is sufficient stuff deployed to central with "poor quality poms"
which do not meet our own criteria for artifact hosting on central, that
central risks being considered "unreliable". Some of these artifacts arose
