« Return to Thread: [VOTE] Release Maven 2.0.5

Re: [VOTE] Release Maven 2.0.5

by John Casey :: Rate this Message:

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 <wsmoak@...> wrote:

>
> On 1/15/07, Fabrice Bellingard <bellingard@...> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

« Return to Thread: [VOTE] Release Maven 2.0.5