IIRC, the order in which dependencies are declared effectively becomes the tie-breaker when two dependency versions are declared at the same depth...so if:
A -> B, C B -> D (v2) C -> D (v3) and A declares the following: <dependencies> <dependency> [...] <artifactId>B</artifactId> </dependency> <dependency> [...] <artifactId>C</artifactId> </dependency> </dependencies> then Maven should choose D (v2) because B is declared first in the POM. As I recall, that's how the change should function. -john On 1/15/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 1/15/07, Fabrice Bellingard <[EMAIL PROTECTED]> wrote: > The first is about dependency resolution. In the dependency tree of one of > my projects, I have 2 versions of the same lib at the same depth: version > 3.1 and 2.1. With Maven 2.0.4, version 3.1 is selected for compiling and > testing, which is what I want. With Maven 2.0.5, version 2.1 is selected, > which breaks my unit tests because the code requires version 3.1 to run. I'm > not sure if this is a bug or not - maybe this resolution principle was to be > the default behaviour, but the fact is that there's a difference between > 2.0.4 and 2.0.5. I've looked (quickly) into JIRA roadmap, but haven't found > any fixed issue related to that. IIRC, Maven 2.0.4's behavior with two versions of the same dependency at the same depth was undefined. Now, it's supposed to be predictable. Can someone confirm? (And explain how to predict what 2.0.5 will do in this situation?) -- Wendy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
