You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Thomas HUGUERRE <Th...@nordnet.fr> on 2009/03/17 14:15:44 UTC

Transitive dependency management issue

Hello,

It is the first time I use this mailing list, I just hope it is the right one.

I am facing a transitive dependency management issue since yesterday. I have checked all the documentation on the Maven web site and found my answer (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html), but I do not understand the choice which has been done on the dependency management policy.

Typically, I have a project A which requires a dependency B:v1 and another dependency C. This last one also requires a dependency B:v2. I suppose the dependency B:v2 is more recent than the B:v1. Due to the "nearest definition" policy, the project A will embed the dependency B:v1, which will cause some failures while executing the dependency C's sources.

I expected that, as the version B:v2 is more recent than the B:v1, it will be considered as priority. This policy could be really useful when a high level project A is the root of a deep dependency hierarchy tree (which is my case right now J).

With the current behavior of the Maven dependency management, it is impossible to list the newest required dependencies (using the plugin dependency:tree for example) and some problems could be really difficult to understand (once the problem has been identified, the resolution is quite easy).

Why does this policy has not been implemented ?
Is it because the version is only a String that you cannot guarantee to compare with another one of the same artifact (all versions are not formatted as X.Y.Z) ?

Is it possible to add this policy on a next release and let the user choosing the one he prefers ?

Thanks per advance for your answer,
Best regards,
Thomas Huguerre
Ingénieur Etudes et Développement
+33 (0) 3.20.66.55.95

Département DISI - NordNet
111, rue de Croix - 59510 HEM - France