1

The scenario: my project enables the maven-enforcer-plugin dependencyConvergence rule. It depends on a library that has corrected its own dependency convergence by using a dependencyManagement declaration, but it doesn't seem to affect the resolution of the dependency versions downstream.

An example of the type of error message I'm talking about (note that both versions are inherited by d as transitive dependencies under the c module):

Dependency convergence error for org.apache.commons:commons-lang3:3.0 paths to dependency are:
+-com.example:d:1.0-SNAPSHOT
  +-com.example:c:1.0-SNAPSHOT
    +-com.example:b:1.0-SNAPSHOT
      +-org.apache.commons:commons-lang3:3.0
and
+-com.example:d:1.0-SNAPSHOT
  +-com.example:c:1.0-SNAPSHOT
    +-org.apache.commons:commons-lang3:3.1

mvn dependency:tree shows similar inconsistency. c has the transitive version managed:

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ c ---
[INFO] com.example:c:jar:1.0-SNAPSHOT
[INFO] +- com.example:b:jar:1.0-SNAPSHOT:compile
[INFO] |  \- (org.apache.commons:commons-lang3:jar:3.1:compile - version managed from 3.0; omitted for duplicate)
[INFO] \- org.apache.commons:commons-lang3:jar:3.1:compile

but d shows it as a conflict:

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ d ---
[INFO] com.example:d:jar:1.0-SNAPSHOT
[INFO] \- com.example:c:jar:1.0-SNAPSHOT:compile
[INFO]    +- com.example:b:jar:1.0-SNAPSHOT:compile
[INFO]    |  \- (org.apache.commons:commons-lang3:jar:3.0:compile - omitted for conflict with 3.1)
[INFO]    \- org.apache.commons:commons-lang3:jar:3.1:compile

It seems like this is a potentially endless problem. If I correct it using dependencyManagement in d, then I'm just pushing the problem downstream to any consumers of d. I can avoid the error by excluding the transitive dependency in the c project's pom, but that's why I have the dependencyManagement declaration in c!

I think this is a bug in Maven, or maybe in the enforcer plugin. Am I missing something? What is the right way to deal with this situation?

Is this a case of http://jira.codehaus.org/browse/MNG-3038 (open since 2007!)? In my case, the dependency is used everywhere along the trail.

Zac Thompson
  • 12,401
  • 45
  • 57
  • Which Maven version do you use? Can you show a full example where this happens? Or more better can you create such example on Github? – khmarbaise Mar 20 '14 at 05:54
  • Maven 3.1 and 3.2 both exhibit the problem. The example above is complete; the poms are trivial: b->lang3:3.0, c->lang3 + depMgmt(lang3:3.1), d->c. – Zac Thompson Mar 20 '14 at 21:12

1 Answers1

0

You are right that this would be a potentially endless problem. This is because you did not fix the dependency in component 'b'. Managing the dependency in 'c' or 'd' does not remove the problem: Component 'b' might either break with the newer version or it might even include commons-lang:3.0. In the latter case you have two different versions of commons-lang in your classpath and it will be sheer luck if your application works correctly.

ralferic
  • 1