Maven 2 & 3

Scope defined in dependencyManagement section of parent pom overwrites scope of current artifact

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.6
  • Fix Version/s: 2.0.7
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

If the dependencyManagement contains also the current artifact with a scope, this scope will overwrite the scope of the current project.

Use case: A global parent POM that defines the released versions of all artifacts. Those artifacts are all defined with "runtime" scope to enforce projects to declare compile time deps (workaround for MNG-2589) or some are declared with scope "test" since they should only be used in unit or it tests.

Problem: If that artifact is build with M206, it does no longer compile.

Reason: The declaration in the dependencyManagement section overwrites also the scope of the current artifact itself i.e. all the declared dependencies are suddenly also no longer in the compile scope.

Solution: The dependencyManagement may not overwrite the scope of the current artifact.

Workaround: Add for the current artifact in its own POM a dependencyManagement section where it is itself declared again with compile scope.

Issue Links

This issue relates to:
MNG-2931 DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joerg Schaible added a comment -

Simple setup to demonstrate the problem.

Show
Joerg Schaible added a comment - Simple setup to demonstrate the problem.
Hide
Permalink
Jason van Zyl added a comment -

I'm not really sure from your explanation with your example what you are trying to say is happening. I'm using "mvn help:effective-pom" on the child POM and seeing the behavior I expect where the junit dependency in the child overrides the scope of what is stated in the parent's depMan element. The child wins as it should. The scope in the child is not overwritten in your sample project. You need to explain better what you want me to look at or what the result should be instead of describing the general and then giving me concrete example that is working as expected.

Show
Jason van Zyl added a comment - I'm not really sure from your explanation with your example what you are trying to say is happening. I'm using "mvn help:effective-pom" on the child POM and seeing the behavior I expect where the junit dependency in the child overrides the scope of what is stated in the parent's depMan element. The child wins as it should. The scope in the child is not overwritten in your sample project. You need to explain better what you want me to look at or what the result should be instead of describing the general and then giving me concrete example that is working as expected.
Hide
Permalink
Jason van Zyl added a comment -

I'm not really sure from your explanation with your example what you are trying to say is happening. I'm using "mvn help:effective-pom" on the child POM and seeing the behavior I expect where the junit dependency in the child overrides the scope of what is stated in the parent's depMan element. The child wins as it should. The scope in the child is not overwritten in your sample project. You need to explain better what you want me to look at or what the result should be instead of describing the general and then giving me concrete example that is working as expected.

Show
Jason van Zyl added a comment - I'm not really sure from your explanation with your example what you are trying to say is happening. I'm using "mvn help:effective-pom" on the child POM and seeing the behavior I expect where the junit dependency in the child overrides the scope of what is stated in the parent's depMan element. The child wins as it should. The scope in the child is not overwritten in your sample project. You need to explain better what you want me to look at or what the result should be instead of describing the general and then giving me concrete example that is working as expected.
Hide
Permalink
Patrick Schneider added a comment - - edited

I am able to reproduce the problem using the sample that Joerg attached. The issue is not with junit, but with the child project itself (issue/pom.xml).

I believe this is an ArtifactCollector problem, probably introduced in the fix to MNG-1577. It may take me a bit of time to figure it out, so maybe we can slate this for 2.0.8?

Show
Patrick Schneider added a comment - - edited I am able to reproduce the problem using the sample that Joerg attached. The issue is not with junit, but with the child project itself (issue/pom.xml). I believe this is an ArtifactCollector problem, probably introduced in the fix to MNG-1577. It may take me a bit of time to figure it out, so maybe we can slate this for 2.0.8?
Hide
Permalink
Jason van Zyl added a comment -

Is this something we can squeeze into 2.0.7?

Show
Jason van Zyl added a comment - Is this something we can squeeze into 2.0.7?
Hide
Permalink
Patrick Schneider added a comment -

I will start work on it this afternoon. Like I said, I'm pretty sure where it's being caused, but I can't say for sure when I'll be done. I guess it depends on when you're looking to ship 2.0.7.

Show
Patrick Schneider added a comment - I will start work on it this afternoon. Like I said, I'm pretty sure where it's being caused, but I can't say for sure when I'll be done. I guess it depends on when you're looking to ship 2.0.7.
Hide
Permalink
Patrick Schneider added a comment -

The interim fix in DefaultArtifactCollector that was submitted against MNG-2931 fixes the version overwriting problem, but not the scope overwriting problem, as in this issue.

Show
Patrick Schneider added a comment - The interim fix in DefaultArtifactCollector that was submitted against MNG-2931 fixes the version overwriting problem, but not the scope overwriting problem, as in this issue.
Hide
Permalink
Patrick Schneider added a comment -

See MNG-2931 for more information. Fixing this bug was a matter of removing the version check from that fix. Basically we don't want to alter the originatingArtifact at all when it's being built. Added unit test the mimics the attached example project.

Show
Patrick Schneider added a comment - See MNG-2931 for more information. Fixing this bug was a matter of removing the version check from that fix. Basically we don't want to alter the originatingArtifact at all when it's being built. Added unit test the mimics the attached example project.
Hide
Permalink
Patrick Schneider added a comment -

Still need to port this up to the trunk – will do so this evening or tomorrow.

Show
Patrick Schneider added a comment - Still need to port this up to the trunk – will do so this evening or tomorrow.
Hide
Permalink
Patrick Schneider added a comment -

Added fix to the trunk.

Show
Patrick Schneider added a comment - Added fix to the trunk.

People

Vote (3)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.