[
http://jira.codehaus.org/browse/MNG-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-4175.
-----------------------------
Resolution: Duplicate
> Dependency mediation - allow for different strategies
> -----------------------------------------------------
>
> Key: MNG-4175
> URL: http://jira.codehaus.org/browse/MNG-4175
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories
> Affects Versions: 2.1.0
> Reporter: Sander Nieuwenhuizen
> Attachments: dependency graph-1.png, dependency graph-2.png
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
