[#MNG-2931] DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version

Maven 2

DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version

Created: 04/Apr/07 08:31 PM Updated: 09/Jul/08 04:55 PM

Component/s:

Artifacts and Repositories

Affects Version/s:

2.0.5, 2.0.6

Fix Version/s:

2.0.11

Time Tracking:

Not Specified

File Attachments:

MNG-2931.patch (1 kB)

Issue Links:

Related

This issue is related to:

~~MNG-2919~~ Scope defined in dependencyManagement section of parent pom overwrites scope of current artifact

Complexity:

Intermediate

Description

« Hide

DefaultDependencyTreeBuilder
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java

calls collect like this

collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository,
project.getRemoteArtifactRepositories(), metadataSource, null,
Collections.singletonList( listener ) );

Problem:
This pom
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom
extends
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom
that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19

so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one

Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Carlos Sanchez added a comment - 04/Apr/07 08:32 PM

unit test

[ Permlink | « Hide ]

Carlos Sanchez added a comment - 04/Apr/07 08:35 PM

The question is do we allow a project to extend another one that has a different version of it in dependencyManagement ?
if we do, then the current project version has to win over the managed one

[ Permlink | « Hide ]

Carlos Sanchez added a comment - 04/Apr/07 08:46 PM

Seems logical to fail the build if dependencyManagement and the project version don't match

[ Permlink | « Hide ]

Joerg Schaible added a comment - 05/Apr/07 12:18 AM

The version of the current artifact has to win! See, we manage all our versions in a global POM and that includes also our released artifacts. However, they are depending on each other. So it is quite normal that an artifact inherits a version from the global POM, but will declare a SNAPSHOT on its own.

[ Permlink | « Hide ]

Carlos Sanchez added a comment - 05/Apr/07 12:49 PM

I can see a cycle

the child can't be released until the parent is
if the parent is released with a released version of the child in depMngmt the child wouldn't run again as its version is still snapshot

[ Permlink | « Hide ]

Carlos Sanchez added a comment - 06/Apr/07 01:33 PM

I added a workaround to the code to avoid changing the originating artifact version until a better solution.

[ Permlink | « Hide ]

Chris Wewerka added a comment - 24/Apr/07 05:54 AM

Very, very ugly effect of this bug is that already deployed versions are overwritten by newer versions without notice. Maven changes the artifact version to the managed version and deploys it to the repository

[ Permlink | « Hide ]

John Casey added a comment - 09/Jul/08 04:53 PM

For clarity, the attached patch has already been applied. (MNG-2931.patch)

[ Permlink | « Hide ]

John Casey added a comment - 09/Jul/08 04:55 PM

We need a clear test case for this issue, or it's going to be nearly impossible to be sure we have it located and fixed.