You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@maven.apache.org by "Paul Gier (JIRA)" <ji...@codehaus.org> on 2010/09/01 23:40:32 UTC

[jira] Created: (MNG-4789) [regression]

[regression]
------------

                 Key: MNG-4789
                 URL: http://jira.codehaus.org/browse/MNG-4789
             Project: Maven 2 & 3
          Issue Type: Bug
          Components: Dependencies
         Environment: maven-3.0-beta-2 vs. maven-3.0-beta-3 (trunk)
            Reporter: Paul Gier
         Attachments: maven-3-dependency-issue.zip

There is a small difference in dependency resolution behaviour from 3.0-beta-2 to 3.0-beta-3.  I have a project with multiple interdependent modules.

module 2 -> module 1 -> thirdparty dep

Module 1 has a compile scope dependency on thirdparty dep.  Module 2 has a test scope dependency on module 1.  Using dependency management, in 3.0-beta-2 module 2 ended up with a test scope dependency on thirdparty.  In 3.0-beta-3 module 2 ends up with a compile scope dependency.  "mvn dependency:tree" reports a test scope in both cases, but with maven-3.0-beta-3 the thirdparty dep appears in the compile classpath.

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

[jira] Commented: (MNG-4789) [regression] Difference in compile scope dependency resolution

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.

    [ http://jira.codehaus.org/browse/MNG-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234141#action_234141 ] 

Benjamin Bentmann commented on MNG-4789:
----------------------------------------

bq. I think I agree with MNG-4156 that a local scope shouldn't override a transitive one
Well, this is controversial and I personally think the current approach of POM-wins is right/consistent, but anyways that's a different issue.

For now, I'm going to restore the 2.x behavior as I don't see a strong use case or existing JIRA that would clearly declare the old behavior as a bug.

bq. Is the aether wiki [1] the correct place to put docs/examples? 
No, not for this issue, Aether isn't bound to a particular resolution strategy. This is about Maven's resolutions rules, so it should be documented on Maven's site.

> [regression] Difference in compile scope dependency resolution
> --------------------------------------------------------------
>
>                 Key: MNG-4789
>                 URL: http://jira.codehaus.org/browse/MNG-4789
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 3.0-beta-3
>         Environment: maven-3.0-beta-2 vs. maven-3.0-beta-3 (trunk)
>            Reporter: Paul Gier
>         Attachments: maven-3-dependency-issue.zip, maven-3-dependency-issue.zip
>
>
> There is a small difference in dependency resolution behaviour from 3.0-beta-2 to 3.0-beta-3.  I have a project with multiple interdependent modules.
> module 2 -> module 1 -> thirdparty dep
> Module 1 has a compile scope dependency on thirdparty dep.  Module 2 has a test scope dependency on module 1.  Using dependency management, in 3.0-beta-2 module 2 ended up with a test scope dependency on thirdparty.  In 3.0-beta-3 module 2 ends up with a compile scope dependency.  "mvn dependency:tree" reports a test scope in both cases, but with maven-3.0-beta-3 the thirdparty dep appears in the compile classpath.

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

[jira] Commented: (MNG-4789) [regression] Difference in compile scope dependency resolution

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.

    [ http://jira.codehaus.org/browse/MNG-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234127#action_234127 ] 

Benjamin Bentmann commented on MNG-4789:
----------------------------------------

The dirty tree (including scope inheritance from the parent node) of the example looks like
{noformat}
project
+- a:test
|  \- x:test
\- b:compile
   \- a:compile
      \- x:compile
{noformat}
There are two conflicts here. The conflict between {{a:test}} and {{a:compile}} is subject of MNG-4156. The conflict between {{x:test}} and {{x:compile}} is subject of this issue. In Maven 2.x, {{test}} was chosen, since 3.0-beta-3 it's {{compile}}. I'm still trying to understand what actually makes most sense, also considerung MNG-1895.

> [regression] Difference in compile scope dependency resolution
> --------------------------------------------------------------
>
>                 Key: MNG-4789
>                 URL: http://jira.codehaus.org/browse/MNG-4789
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 3.0-beta-3
>         Environment: maven-3.0-beta-2 vs. maven-3.0-beta-3 (trunk)
>            Reporter: Paul Gier
>         Attachments: maven-3-dependency-issue.zip
>
>
> There is a small difference in dependency resolution behaviour from 3.0-beta-2 to 3.0-beta-3.  I have a project with multiple interdependent modules.
> module 2 -> module 1 -> thirdparty dep
> Module 1 has a compile scope dependency on thirdparty dep.  Module 2 has a test scope dependency on module 1.  Using dependency management, in 3.0-beta-2 module 2 ended up with a test scope dependency on thirdparty.  In 3.0-beta-3 module 2 ends up with a compile scope dependency.  "mvn dependency:tree" reports a test scope in both cases, but with maven-3.0-beta-3 the thirdparty dep appears in the compile classpath.

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