Dependency mediation - allow for different strategies

Currently there is one strategy for handling artifact resolution conflicts: the nearest match wins. That means that the order of artifacts in your POM matters. For an example see attachment 1. Your main artifact A depends on B, C and D which in turn depend on E. However, B, C and D depend on different versions of E. If B is the first dependency in your POM, then A would have a dependency on version 1.0.0 of E (see attach 2). If you'd list D as your first dependency, you would end up with E 1.5.0.

simple work arounds
There are a couple of simple solutions available:

• List E in A's POM with the required version
  this is more or less in conflict with transitive dependency management
• Change the order in A's POM to make sure D is the first artifact
  which is quite a tedious and error prone task

In large environments which heavily rely on component based architecture - and as such require advanced dependency mediation - these work around are not really applicable. You would like to have A's POM as clean as possible and make sure B, C and D get their dependencies by transitive dependency management.

Opt for alternate mediation
I think the nearest wins scheme suits most users. However, in more complex en larger environments you'd probably need something more enhanced. My idea is to compare the versions of E, no matter the depth of E in your tree. Then use the Default Version comparison definition described at http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution. Then do the following:

• If there's a major version difference of E (2.x.y vs 1.u.v) -> I would say raise an error (not yet made up my mind about this)
• If there's a minor version difference of E (1.5.x vs 1.0.y) -> Choose the highest one
• If there's a revision (or bugfix) version difference of E (1.1.x vs 1.1.y) -> Choose the highest one

Maybe this suits only me, but then still it would be nice to be able to implement this custom scheme. Currently this is not possible.