You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Sander Nieuwenhuizen (JIRA)" <ji...@codehaus.org> on 2009/05/26 11:08:42 UTC
[jira] Created: (MNG-4175) Dependency mediation - allow for
different strategies
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
[jira] Closed: (MNG-4175) Dependency mediation - allow for
different strategies
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ 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