[
http://jira.codehaus.org/browse/MECLIPSE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165973#action_165973
]
Jason Tholstrup commented on MECLIPSE-348:
------------------------------------------
I'd just like to see where you guys are at with this one. I see it is listed
as critical but the last status on it is from 2007. I can verify that I too
see this issue, and I also have a little more info to provide on it.
I have project1 and project2.
project -> dependencies
----------------------------------
project1 -> project2, dependency-1.0
project2 -> dependency-1.1
Here I will resolve get dependency-1.1 when I look at the dependency hierarchy.
======
If however I flip the order of the dependencies in project1.....
project -> dependencies
----------------------------------
project1 -> dependency-1.0, project2
project2 -> dependency-1.1
I get dependency-1.0. It looks as if the resolver is doing a depth first
search and just taking the first version it comes to.
=======
It would be great if we could see a resolution on this one as I think this is
exactly why a lot of us use maven. If nothing else I hope my notes above
might provide a work around for others though if you have a very complex pom
structure it might cause more problems than it solves.
> Transitive dependencies are resolved in an inhomogeneous manner
> ---------------------------------------------------------------
>
> Key: MECLIPSE-348
> URL: http://jira.codehaus.org/browse/MECLIPSE-348
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
> Affects Versions: 2.4
> Environment: Maven 2.0.7, Windows XP SP 2, JDK 1.5.0
> Reporter: Michael Albrecht
> Priority: Critical
> Attachments: module.zip
>
>
> There are four modules/projects moduleA, moduleB, moduleC and moduleD.
> moduleA depends on moduleB-1.0.jar
> moduleC depends on moduleB-2.0.jar
> moduleD depends on moduleC-1.0.jar and moduleA-1.0.jar
> What constellation has to be built if I build moduleD-1.0.jar without
> explicit dependency management?
> In my opinion D should be built with A-1.0.jar, B-2.0.jar, C-1.0.jar and
> (hopefully) A-1.0.jar can also run with this version.
> This even happens with the common mvn goals like e.g. mvn test:
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running AppTest
> call me from modulD
> call me from modulC
> call me from modulB - Version 2.0
> call me from modulA
> call me from modulB - Version 2.0
> But with mvn eclipse:eclipse I will get the following classpathentries:
> <classpathentry kind="var" path="M2_REPO/.../modulA/1.0/modulA-1.0.jar"/>
> <classpathentry kind="var" path="M2_REPO/.../modulB/1.0/modulB-1.0.jar"/>
> <classpathentry kind="var" path="M2_REPO/.../modulC/1.0/modulC-1.0.jar"/>
> That's inhomogenous.
> What can I do to resolve it (without dependency management, of course)?
--
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
