You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2010/08/11 17:59:32 UTC

[jira] Created: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Plugin-level dependency scope causes some plugin classpaths to be incorrect
---------------------------------------------------------------------------

                 Key: MNG-4761
                 URL: http://jira.codehaus.org/browse/MNG-4761
             Project: Maven 2 & 3
          Issue Type: Bug
          Components: Artifacts and Repositories, Plugins and Lifecycle
    Affects Versions: 3.0-beta-1, 2.2.1
            Reporter: John Casey
         Attachments: obscured-nearer-dep.zip

Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.


Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.

This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.

The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.

This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Updated: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey updated MNG-4761:
----------------------------

    Attachment: MNG-4761-mvn3b2.reformatted.patch

Fixed to remove unrelated reformats.

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>            Assignee: John Casey
>         Attachments: MNG-4761-mvn3b2.patch, MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Updated: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey updated MNG-4761:
----------------------------

    Affects Version/s: 3.0-beta-2

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>         Attachments: obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Updated: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey updated MNG-4761:
----------------------------

    Attachment: MNG-4761-mvn3b2.patch

Patch to force all plugin-level dependencies to use scope: runtime. We could probably use a debug statement showing this scope being managed to runtime, but the patch works.

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>         Attachments: MNG-4761-mvn3b2.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231708#action_231708 ] 

Benjamin Bentmann commented on MNG-4761:
----------------------------------------

For future reference, the failing test scenario centeres around the following dirty tree for the plugin depencencies:
{noformat}
plugin
+- override:0.1:compile
|  \- middle:0.1:compile        <-----------\
|     \- required:0.1:compile    <---\      |
+- direct:0.1:runtime                (a)    |
|  +- required:0.1:runtime       <---/      |
|  \- middle:0.1:runtime        <--------- (b)
|     \- required:0.1:runtime               |
\- middle:0.2:runtime           <-----------/
{noformat}
During resolution of conflict (a), the node {{required:0.1:runtime}} will be disabled in favor of {{required:0.1:compile}}, although the runtime-scope dependency is nearer, i.e. Maven's usual conflict resolution strategy of nearest-wins is violated here. When conflict (b) is resolved, all {{middle:0.1:*}} nodes including their children will be disabled, thereby completely losing {{required:0.1}} on the plugin class path.

So while using runtime scope for the project-level plugin dependencies workarounds the problem, the issue remains for ordinary project dependency resolution. I wonder if it got filled already.

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>            Assignee: John Casey
>             Fix For: 2.2.2, 3.0-beta-3
>
>         Attachments: MNG-4761-mvn3b2.patch, MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Closed: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey closed MNG-4761.
---------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.2

all scopes EXCEPT system will be forced to runtime for plugin-level dependencies.

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>            Assignee: John Casey
>             Fix For: 2.2.2, 3.0-beta-3
>
>         Attachments: MNG-4761-mvn3b2.patch, MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Updated: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey updated MNG-4761:
----------------------------

    Patch Submitted: [Yes]

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>         Attachments: MNG-4761-mvn3b2.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

-- 
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] Updated: (MNG-4761) Plugin-level dependency scope causes some plugin classpaths to be incorrect

Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Casey updated MNG-4761:
----------------------------

    Fix Version/s: 3.0-beta-3

> Plugin-level dependency scope causes some plugin classpaths to be incorrect
> ---------------------------------------------------------------------------
>
>                 Key: MNG-4761
>                 URL: http://jira.codehaus.org/browse/MNG-4761
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories, Plugins and Lifecycle
>    Affects Versions: 2.2.1, 3.0-beta-1, 3.0-beta-2
>            Reporter: John Casey
>            Assignee: John Casey
>             Fix For: 3.0-beta-3
>
>         Attachments: MNG-4761-mvn3b2.patch, MNG-4761-mvn3b2.reformatted.patch, obscured-nearer-dep.zip
>
>
> Plugin-level dependencies should use RUNTIME scope at all times. Using any other scope may alter the weighting given to the subgraph-choice algorithm used in transitive dependency resolution.
> Plugin-level dependencies use compile scope by default. When transitive resolution takes place, compile scope takes precedence over runtime scope, causing the transitive dependency sub-graph of the plugin-level dependency to be activated over those of the plugin itself.
> This happens even when the plugin's transitive dep is NEARER to the top level than the one brought in by that plugin-level dependency itself.
> The result is that when a dep that's farther away is chosen over a nearer one, it can then be disabled by Maven choosing to disable its parent dep (the one that brought it in) in another part of the transitive resolution process.
> This is a very subtle case where Maven is doing the wrong thing. The attached test case should make it clearer.

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