We can support this behavior in 3.x.
PomTransformer.transformToModelProperties occurs before general inheritance.
We could put the rule in there to remove the first dependency before we
apply inheritance.

Shane

On Mon, Jan 26, 2009 at 10:51 AM, Benjamin Bentmann <
[email protected]> wrote:

> Hi,
>
> Shane and I found some other oddity. Consider this POM snippet extracted
> from [0] that declares two direct dependencies on commons-collection but
> with different versions:
>
>  <dependencies>
>    <dependency>
>      <groupId>commons-collections</groupId>
>      <artifactId>commons-collections</artifactId>
>      <version>2.0</version>
>    </dependency>
>    <dependency>
>      <groupId>commons-collections</groupId>
>      <artifactId>commons-collections</artifactId>
>      <version>3.1</version>
>    </dependency>
>  </dependencies>
>
> Now, what version will make it onto the effective class paths? At least in
> Maven 2.x it's commons-collection:3.1, i.e. the last declaration, apparently
> due to DefaultModelInheritanceAssembler.assembleDependencyInheritance() when
> constructing the depsMap.
>
> This behavior is inconsistent with regard to conflict resolution where we
> otherwise have first declaration wins [1]. How do we go about this?
>
> I assume one thing is to have model validation error out during a local
> build if a single POM declares two direct dependencies that differ only by
> version.
>
> The other thing is, do we eventually want to change the dependency
> resolution in 2.1.x or 3.x to be first-wins here? Obviously, this would
> affect already deployed bad POMs on central, potentially requiring their
> consumers to use dependency management to compensate for the change in class
> path.
>
>
> Benjamin
>
>
> [0]
> http://fisheye.codehaus.org/browse/plexus/plexus-components/trunk/plexus-velocity/pom.xml?r=8074
> [1]
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to