Maven 2 & 3

[regression] Difference in compile scope dependency resolution

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.0-beta-3
  • Fix Version/s: 3.0
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    maven-3.0-beta-2 vs. maven-3.0-beta-3 (trunk)
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

There is a small difference in dependency resolution behaviour from 3.0-beta-2 to 3.0-beta-3. I have a project with multiple interdependent modules.

module 2 -> module 1 -> thirdparty dep

Module 1 has a compile scope dependency on thirdparty dep. Module 2 has a test scope dependency on module 1. Using dependency management, in 3.0-beta-2 module 2 ended up with a test scope dependency on thirdparty. In 3.0-beta-3 module 2 ends up with a compile scope dependency. "mvn dependency:tree" reports a test scope in both cases, but with maven-3.0-beta-3 the thirdparty dep appears in the compile classpath.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-1895 Dependencies in two paths are not added to resolution when scope needs to be updated in the nearest due to any of nearest parents

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-4156 Local test scope shouldn't override transitive compile scope

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-4800 Conflict resolution does not pick sub tree of nearest dependency if farther conflicting dependency has wider scope

  • Major - Major loss of function.
  • 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
Paul Gier added a comment -

This previous discussion also seems relevant:
http://maven.40175.n5.nabble.com/Transitive-and-inherited-dependencies-potential-bug-or-my-misunderstanding-of-the-mechanism-td119738.html#a119738

Show
Paul Gier added a comment - This previous discussion also seems relevant: http://maven.40175.n5.nabble.com/Transitive-and-inherited-dependencies-potential-bug-or-my-misunderstanding-of-the-mechanism-td119738.html#a119738
Hide
Permalink
Benjamin Bentmann added a comment -

The dirty tree (including scope inheritance from the parent node) of the example looks like

project
+- a:test
|  \- x:test
\- b:compile
   \- a:compile
      \- x:compile

There are two conflicts here. The conflict between a:test and a:compile is subject of MNG-4156. The conflict between x:test and x:compile is subject of this issue. In Maven 2.x, test was chosen, since 3.0-beta-3 it's compile. I'm still trying to understand what actually makes most sense, also considerung MNG-1895.

Show
Benjamin Bentmann added a comment - The dirty tree (including scope inheritance from the parent node) of the example looks like project +- a:test | \- x:test \- b:compile \- a:compile \- x:compile There are two conflicts here. The conflict between a:test and a:compile is subject of MNG-4156 . The conflict between x:test and x:compile is subject of this issue. In Maven 2.x, test was chosen, since 3.0-beta-3 it's compile . I'm still trying to understand what actually makes most sense, also considerung MNG-1895 .
Hide
Permalink
Paul Gier added a comment -

I think I agree with MNG-4156 that a local scope shouldn't override a transitive one. In this case I think the correct behaviour would be to assume both scopes are valid, so the resulting scope would be compile. So I think the way it's done in 3.0-beta-3 is correct, as long as there is documentation explaining how/why the decision is made. Is the aether wiki [1] the correct place to put docs/examples?
I'm also attaching a more minimal project demonstrating the issue.

[1]https://docs.sonatype.org/display/AETHER/Home

Show
Paul Gier added a comment - I think I agree with MNG-4156 that a local scope shouldn't override a transitive one. In this case I think the correct behaviour would be to assume both scopes are valid, so the resulting scope would be compile. So I think the way it's done in 3.0-beta-3 is correct, as long as there is documentation explaining how/why the decision is made. Is the aether wiki [1] the correct place to put docs/examples? I'm also attaching a more minimal project demonstrating the issue. [1] https://docs.sonatype.org/display/AETHER/Home
Hide
Permalink
Benjamin Bentmann added a comment -

I think I agree with MNG-4156 that a local scope shouldn't override a transitive one

Well, this is controversial and I personally think the current approach of POM-wins is right/consistent, but anyways that's a different issue.

For now, I'm going to restore the 2.x behavior as I don't see a strong use case or existing JIRA that would clearly declare the old behavior as a bug.

Is the aether wiki [1] the correct place to put docs/examples?

No, not for this issue, Aether isn't bound to a particular resolution strategy. This is about Maven's resolutions rules, so it should be documented on Maven's site.

Show
Benjamin Bentmann added a comment - I think I agree with MNG-4156 that a local scope shouldn't override a transitive one Well, this is controversial and I personally think the current approach of POM-wins is right/consistent, but anyways that's a different issue. For now, I'm going to restore the 2.x behavior as I don't see a strong use case or existing JIRA that would clearly declare the old behavior as a bug. Is the aether wiki [1] the correct place to put docs/examples? No, not for this issue, Aether isn't bound to a particular resolution strategy. This is about Maven's resolutions rules, so it should be documented on Maven's site.
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r996468.

Show
Benjamin Bentmann added a comment - Fixed in r996468 .

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Paul Gier
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: