Transitive dependencies are resolved in an inhomogeneous manner

Details

  • Testcase included:
    yes

Description

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)?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Arnaud Heritier added a comment -

I reproduced your problem
There's certainly a bug in the dependency resolution strategy used by the plugin

Show
Arnaud Heritier added a comment - I reproduced your problem There's certainly a bug in the dependency resolution strategy used by the plugin
Hide
Permalink
Jason Tholstrup added a comment -

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.

Show
Jason Tholstrup added a comment - 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.
Hide
Permalink
Michael Albrecht added a comment -

"It looks as if the resolver is doing a depth first search and just taking the first version it comes to."

This is exactly the documented behaviour from Maven, but the maven-eclipse-plugin does it in another way.
I thought that's the problem.

Show
Michael Albrecht added a comment - "It looks as if the resolver is doing a depth first search and just taking the first version it comes to." This is exactly the documented behaviour from Maven, but the maven-eclipse-plugin does it in another way. I thought that's the problem.
Hide
Permalink
Jason Tholstrup added a comment -

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.

Show
Jason Tholstrup added a comment - 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.
Hide
Permalink
Michael Albrecht added a comment -

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

Show
Michael Albrecht added a comment - 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

People

  • Assignee:
    Unassigned
    Reporter:
    Michael Albrecht
Vote (2)
Watch (3)

Dates

  • Created:
    Updated: