You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2009/01/26 19:51:29 UTC
Precedence of direct dependencies with equal conflict id
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Precedence of direct dependencies with equal conflict id
Posted by Brian Fox <br...@reply.infinity.nu>.
Good point, I didn't consider things in a repo. We'll have to take the
last one in that case.
--Brian (mobile)
On Jan 26, 2009, at 6:21 PM, Brett Porter <br...@apache.org> wrote:
>
> On 26/01/2009, at 12:17 PM, Brian E. Fox wrote:
>
>> It should be a validation error if we find duplicated entries.
>
> +1 when building a project. Probably not when encountered in the
> repository (but changing the first would reduce the impact over time).
>
> - Brett
>
>>
>>
>> -----Original Message-----
>> From: Shane Isbell [mailto:shane.isbell@gmail.com]
>> Sent: Monday, January 26, 2009 1:58 PM
>> To: Maven Developers List
>> Subject: Re: Precedence of direct dependencies with equal conflict id
>>
>> 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 <
>> benjamin.bentmann@udo.edu> 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-m
>> echanism.html#Transitive_Dependencies
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Precedence of direct dependencies with equal conflict id
Posted by da...@davidkarlsen.com.
On Mon, 26 Jan 2009, Brett Porter wrote:
>
> On 26/01/2009, at 12:17 PM, Brian E. Fox wrote:
>
>> It should be a validation error if we find duplicated entries.
>
> +1 when building a project. Probably not when encountered in the repository
> (but changing the first would reduce the impact over time).
will relocated artifacts be taken into consideration as well - or is that
too fancy?
--
David J. M. Karlsen - +47 90 68 22 43
http://www.davidkarlsen.com
http://mp3.davidkarlsen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Precedence of direct dependencies with equal conflict id
Posted by Brett Porter <br...@apache.org>.
On 26/01/2009, at 12:17 PM, Brian E. Fox wrote:
> It should be a validation error if we find duplicated entries.
+1 when building a project. Probably not when encountered in the
repository (but changing the first would reduce the impact over time).
- Brett
>
>
> -----Original Message-----
> From: Shane Isbell [mailto:shane.isbell@gmail.com]
> Sent: Monday, January 26, 2009 1:58 PM
> To: Maven Developers List
> Subject: Re: Precedence of direct dependencies with equal conflict id
>
> 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 <
> benjamin.bentmann@udo.edu> 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-m
> echanism.html#Transitive_Dependencies
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Precedence of direct dependencies with equal conflict id
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
It should be a validation error if we find duplicated entries.
-----Original Message-----
From: Shane Isbell [mailto:shane.isbell@gmail.com]
Sent: Monday, January 26, 2009 1:58 PM
To: Maven Developers List
Subject: Re: Precedence of direct dependencies with equal conflict id
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 <
benjamin.bentmann@udo.edu> 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-m
echanism.html#Transitive_Dependencies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Precedence of direct dependencies with equal conflict id
Posted by Shane Isbell <sh...@gmail.com>.
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 <
benjamin.bentmann@udo.edu> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>