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

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: 2.0.5, 2.0.6
  • Fix Version/s: None
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate

Description

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

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-2919 Scope defined in dependencyManagement section of parent pom overwrites scope of current artifact

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Carlos Sanchez added a comment -

unit test

Show
Carlos Sanchez added a comment - unit test
Hide
Permalink
Carlos Sanchez added a comment -

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

Show
Carlos Sanchez added a comment - 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
Hide
Permalink
Carlos Sanchez added a comment -

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

Show
Carlos Sanchez added a comment - Seems logical to fail the build if dependencyManagement and the project version don't match
Hide
Permalink
Joerg Schaible added a comment -

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.

Show
Joerg Schaible added a comment - 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.
Hide
Permalink
Carlos Sanchez added a comment -

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

Show
Carlos Sanchez added a comment - 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
Hide
Permalink
Carlos Sanchez added a comment -

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

Show
Carlos Sanchez added a comment - I added a workaround to the code to avoid changing the originating artifact version until a better solution.
Hide
Permalink
Chris Wewerka added a comment -

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

Show
Chris Wewerka added a comment - 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
Hide
Permalink
John Casey added a comment -

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

Show
John Casey added a comment - For clarity, the attached patch has already been applied. (MNG-2931.patch)
Hide
Permalink
John Casey added a comment -

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.

Show
John Casey added a comment - 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.

People

  • Assignee:
    Unassigned
    Reporter:
    Carlos Sanchez
Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: