Maven 2 & 3

dependency:resolve decides to take older (incompatible) version for transitive dep

Details

  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Number of attachments :
    2

Description

I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain the case.

Parent specifies commons-net/1.3.0 in dependencyManagement
- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves correctly 1.4.1
- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net), and resolves erroneously 1.3.0
- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it

I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or ModuleC).

I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours and runtime errors) with this kind silent down-resolution of version.

Regards,
Paolo

Issue Links

This issue is related to:
MNG-1577 dependencyManagement does not work for transitive dependencies Major Closed

Activity

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

This works exactly as defined. The depMgmt section is used to override even transitive deps.

Show
Joerg Schaible added a comment - This works exactly as defined. The depMgmt section is used to override even transitive deps.
Hide
Permalink
Brian Fox added a comment -

This isn't dependency plugin functionality, it's core.

However what you describe is correct. From Module A's point of view, the dependencyManagement overrides the transitive dependency version of 1.3.0.

See MNG-1577 for more information.

Show
Brian Fox added a comment - This isn't dependency plugin functionality, it's core. However what you describe is correct. From Module A's point of view, the dependencyManagement overrides the transitive dependency version of 1.3.0. See MNG-1577 for more information.
Hide
Permalink
Brian Fox added a comment -

The bug appears to describe that MNG-1577 is working as intended.

Show
Brian Fox added a comment - The bug appears to describe that MNG-1577 is working as intended.
Hide
Permalink
Paolo Compieta added a comment -

I agree with MNG-1577, but there are a few differences here, so i'm kindly asking more clarifications.

1) no one is using 1.3.0 in the build, but Maven resolves 1.3.0 -could we point this out during the build or better manage this case?
2) Maven chooses the older version (not a newer one) while B is declaring a direct dep with an explicit,newer version -could we could point this out with a short message? [also a short hint in the dep resolution phase would be ok: "some deps older than requested"]
3) why is A's-transitive-older-managed-dep winning over B's direct-dep? Is this right?

Regarding point 3), i could agree if there were (another) ModuleD with direct-dep inheriting version 1.3.0 from parent: in this case, resolving 1.3.0 instead of 1.4.1 would be fair (see attached example).

Show
Paolo Compieta added a comment - I agree with MNG-1577, but there are a few differences here, so i'm kindly asking more clarifications. 1) no one is using 1.3.0 in the build, but Maven resolves 1.3.0 -could we point this out during the build or better manage this case? 2) Maven chooses the older version (not a newer one) while B is declaring a direct dep with an explicit,newer version -could we could point this out with a short message? [also a short hint in the dep resolution phase would be ok: "some deps older than requested"] 3) why is A's-transitive-older-managed-dep winning over B's direct-dep? Is this right? Regarding point 3), i could agree if there were (another) ModuleD with direct-dep inheriting version 1.3.0 from parent: in this case, resolving 1.3.0 instead of 1.4.1 would be fair (see attached example).
Hide
Permalink
Brian Fox added a comment - - edited

1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring 1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly MNG-1577

2)There is a message in the logs about selecting one version over another because of a "managed" version. Maven assumes that since you asked for this version, you know it's supposed to be used. A warning is in appropriate in this case and thus the debug message. If we printed even an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than requested" is not true, 1.3.0 was requested by DepMgt in the case of A.

3)Most likely because C is also managing the dependency down to 1.3.0 by inheriting the DepMgt from the parent. Otherwise it would pick the closest version which in this case would be 1.4.1

Show
Brian Fox added a comment - - edited 1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring 1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly MNG-1577 2)There is a message in the logs about selecting one version over another because of a "managed" version. Maven assumes that since you asked for this version, you know it's supposed to be used. A warning is in appropriate in this case and thus the debug message. If we printed even an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than requested" is not true, 1.3.0 was requested by DepMgt in the case of A. 3)Most likely because C is also managing the dependency down to 1.3.0 by inheriting the DepMgt from the parent. Otherwise it would pick the closest version which in this case would be 1.4.1
Hide
Permalink
Paolo Compieta added a comment - - edited

1) ok
2) ok
3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest

I still see this last case as a problem:

  • A resolves 1.3.0 via B via DepMgmt, 2 hops
  • B has 1.4.1, 1 hop

So, should B win? (case: m2WrongTransitiveDepResolve.zip)
If no, i agree to close this issue.

Show
Paolo Compieta added a comment - - edited 1) ok 2) ok 3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest I still see this last case as a problem:
  • A resolves 1.3.0 via B via DepMgmt, 2 hops
  • B has 1.4.1, 1 hop
So, should B win? (case: m2WrongTransitiveDepResolve.zip) If no, i agree to close this issue.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
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.