Maven 2 & 3

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

Details

  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    3

Description

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.

  1. Text File
    MNG-4761-mvn3b2.patch
    11/Aug/10 11:15 AM
    7 kB
    John Casey
  2. Text File
    MNG-4761-mvn3b2.reformatted.patch
    11/Aug/10 11:27 AM
    0.8 kB
    John Casey

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-4134 Conflict resolution with scope widening can cause transitive dependencies to be omitted

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-4790 Dependency resolution issue with provided scope

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4800 Conflict resolution does not pick sub tree of nearest dependency if farther conflicting dependency has wider scope

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

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.

Show
John Casey added a comment - 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.
Hide
Permalink
John Casey added a comment -

Fixed to remove unrelated reformats.

Show
John Casey added a comment - Fixed to remove unrelated reformats.
Hide
Permalink
John Casey added a comment -

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

Show
John Casey added a comment - all scopes EXCEPT system will be forced to runtime for plugin-level dependencies.
Hide
Permalink
Benjamin Bentmann added a comment -

For future reference, the failing test scenario centeres around the following dirty tree for the plugin depencencies:

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

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.

Show
Benjamin Bentmann added a comment - For future reference, the failing test scenario centeres around the following dirty tree for the plugin depencencies: 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 <-----------/ 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.

People

  • Assignee:
    John Casey
    Reporter:
    John Casey
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: