[
http://jira.codehaus.org/browse/MECLIPSE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166265#action_166265
]
Michael Albrecht commented on MECLIPSE-348:
-------------------------------------------
The truth?! Ok, I thought it in your way, too, but Maven documentation
disabused me.
s.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
After all that reading and thinking over I'm sure it's the better way to do in
it a graph and get the nearest definition.
The nearer the definition is the merrier it is, isn't and if you want the
"latest and highest" version number.
You can set it by interval terms, e.g. [2.5, )
The solution we both thought should be the right is fatal and corrupt.
Think about it ;-)
> 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