[
http://jira.codehaus.org/browse/MECLIPSE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166118#action_166118
]
Jason Tholstrup commented on MECLIPSE-348:
------------------------------------------
I must be confused somewhere here then. I thought the expected behavior was to
get the highest version of the jar that was required. So if in your dependency
graph you required (v1, v1.1, and v2), v2 should be returned regardless of the
order the dependency walker found them.
Where are you finding this documented maven behavior? I've always found it
difficult to navigate through their documentation. To be clear here I'm not
trying to argue with you I'm just trying to figure out if this is a bug or if
it is a enhancement request and who I should direct the request to (Maven 2.x
Eclipse Plugin, m2eclipe, or maven).
And just as a point of information for myself: I am a bit confused as to the
difference between Maven 2.x Eclipse Plugin and m2eclipse. It'd be good to
understand the community's organization so I don't pester the wrong people with
my stupid questions. :)
> 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
