You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tomo Suzuki (JIRA)" <ji...@apache.org> on 2019/04/23 20:59:00 UTC

[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first

    [ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824520#comment-16824520 ] 

Tomo Suzuki edited comment on MNG-6357 at 4/23/19 8:58 PM:
-----------------------------------------------------------

I encountered this issue today. I had an assumption that Maven exec plugin builds a class path in "nearest first" manner, but it actually treats it in "depth first" manner.

Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .

Given this tree of transitive dependencies Artifact 1 - 5.

{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
 {{ +- suztomo:artifact1}}
 {{ | - suztomo:artifact4}}
 {{ +- suztomo:artifact2}}
 {{ | - suztomo:artifact5}}
 {{ +- suztomo:artifact3}} 

I expected Maven exec plugin to build a class path of "artifact1, artifact2, artifact3, artifact4, artifact5". However it builds a class path of "artifact1, artifact*4*, artifact2, artifact*5*, artifact3".

 

 

In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91], rfscholte wrote

_>Hervé confirmed that the "nearest wins" is only about version selection and not about dependency order. This order is simply done by tree-walking. However, we agreed that it would make sense to compile based on the direct dependencies first, followed by first level, second level, etc._ 

Thank you. I also think that's intuitive behavior, in line with Maven's dependency mediation algorithm.

 


was (Author: suztomo):
I encountered this issue today. I had an assumption that Maven exec plugin builds a class path in "nearest first" manner, but it actually treats it in "depth first" manner.

Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .

Given this tree of transitive dependencies Artifact 1 - 5.

{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | - suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | - suztomo:artifact5}}
{{ \- suztomo:artifact3}} 

I expected Maven exec plugin to build a class path of "artifact1, artifact2, artifact3, artifact4, artifact5". However it builds a class path of "artifact1, artifact*4*, artifact2, artifact*5*, artifact3".

 

 

In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91], rfscholte wrote

_>Hervé confirmed that the "nearest wins" is only about version selection and not about dependency order. This order is simply done by tree-walking. However, we agreed that it would make sense to compile based on the direct dependencies first, followed by first level, second level, etc._ 

Thank you. I also think that's intuitive behavior, in line with Maven's dependency mediation algorithm.

 

> Dependency order should be nearest first 
> -----------------------------------------
>
>                 Key: MNG-6357
>                 URL: https://issues.apache.org/jira/browse/MNG-6357
>             Project: Maven
>          Issue Type: Improvement
>            Reporter: Robert Scholte
>            Priority: Major
>
> In case of version conflicts, the nearest wins. However, the dependency order is simply based on tree walking. In the rare that a transitive dependency of the first direct dependency contains the same class as a latter direct dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the classpath, followed by the first level transitive dependencies, etc. This will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had this issue much earlier. This should become the new default order, however there should be a system property to get the original order, just in case somebody needs it.
>  
> Current workaround: make the critical dependency the first direct dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)