|
Hi Nicolas, So, the problem is that Maven 2.0.4 and 2.0.5 bahave different when the dependency information has errors!? If the "workaround" is to correct the POM, shouldn't this be a "will not be resolved" case? As explained in http://www.nabble.com/Re%3A--VOTE--Release-Maven-2.0.5-p8382858s177.html The case explained here seems to be affected by this precise dependency resolution change. But all this information is taken from a mailing list, referring to "IIRC" : I don't know who can confirm the information and close this issue. After looking at this specific case, you are doing something that we do not recommend. If the project you are working has a direct dependency which you require for compilation then you should be specifying it. I realize something has changed, but you should be specifying. And the behavior in 2.0.5 is actually more correct according to our select the nearest strategy. If you rearrange the dependencies and put the dependency that has a dependency on commons-collections 3.0 then the builds works fine. The behavior in 2.0.5 is correct and is the behavior we actually have documented. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Maven 2.0.4 uses the "nearest" strategy to solve dependency conflicts, so the issue
"
project depends on A -> D-v2
project depends on B -> D-v3
"
has no determinist solution about what version of D will be transitively used. Having this work in maven 2.0.4 in some circonstances is only beeing lucky. If your project depends on classes from D v3, you should declare it as a dependency to solve the conflict.
there is some plan to enhance the resolution strategy with (http://docs.codehaus.org/display/MAVENUSER/Improving+Maven2+Dependency+Resolution
)
but AFAIK the target is maven 2.1.