Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 30 May 2013 15:49:52 -0500 (CDT)
From: "Ronald Chen (JIRA)" <jira@codehaus.org>
To: issues@maven.apache.org
Message-ID: 
 <JIRA.131392.1320877879365.33677.1369946992888@codehaus01.managed.contegix.com>
In-Reply-To: <JIRA.131392.1320877879365@codehaus01.managed.contegix.com>
References: <JIRA.131392.1320877879365@codehaus01.managed.contegix.com>
Subject: [jira] (MNG-5197) locally declared test dependency's
 first-generation transitive dependency version incorrectly overrides (n >
 1)th-generation compile-scoped dependency version
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


    [ https://jira.codehaus.org/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325953#comment-325953 ] 

Ronald Chen edited comment on MNG-5197 at 5/30/13 3:48 PM:
-----------------------------------------------------------

This is a huge problem.

One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency!

What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution.

So in thing3 the shortest path to hamcrest-core is though junit.  This should be considered a bug because we want hamcrest-core as a COMPILE scope, but junit is declared as TEST scope, so its transitive dependencies should be considered TEST scope and not participate in dependency resolution.

I verified this is still a bug in 3.0.5

The workaround is to excludes hamcrest-core from the junit dependency.
                
      was (Author: pyrolistical):
    This is a huge problem.

One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency!

What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution.

So in thing3 the shortest path to hamcrest-core is though junit.  This should be considered a bug because we want hamcrest-core as a COMPILE scope, but the one through junit is declared as TEST scope

I verified this is still a bug in 3.0.5

The workaround is to excludes hamcrest-core from the junit dependency.
                  
> locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5197
>                 URL: https://jira.codehaus.org/browse/MNG-5197
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 2.2.1, 3.0.3
>         Environment: OSX, Windows 7
>            Reporter: Matt Benson
>         Attachments: test-versions.tar.gz
>
>
> This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I have opened a new issue since nothing I found while searching could be described in precisely the same way.
> The test project I am attaching defines three modules:
> thing1
> thing2
> thing3
> thing1 depends on hamcrest-core 1.2
> thing2 depends on thing1 and junit 4.10
> thing3 depends on thing2 and junit 4.10
> If you install these, you can then view the dependency trees for thing2 and thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core.  thing3, however, apparently overrides the version back to 1.1, apparently accessed transitively via junit.
> Thanks to Mark Struberg for his help in isolating this behavior!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira