Maven
  1. Maven
  2. MNG-3426

regression : <dependency> in plugin configuration doesn't override plugin classpath

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.8
    • Fix Version/s: 2.0.9
    • Component/s: Plugin API
    • Labels:
      None

      Description

      Many maven plugins are wrapper around other tools. The plugin is designed for a version of the tool, and in many case user will want to use a specific version without having to patch the plugin. The <dependency> element on plugin configuration is a common way to do this, by overriding the plugin POM dependency with another version.

      <plugin>
      <artifactId>castor-maven-plugin</artifactId>
      <dependencies>
      <dependency>
      <groupId>org.codehaus.castor</groupId>
      <artifactId>castor</artifactId>
      <version>VERSION OF CASTOR I WANT TO USE FOR CODE GENERATION</version>
      </dependency>
      </dependencies>
      </plugin>

      This used to work with maven < 2.0.8

      In maven 2.0.8, this doesn't work anymore as the <dependency> set in plugin configuration is added to plugin classpath, as a duplicate for the one declared by the plugin but LATER in the classpath (but I may be wrong on this analysis).

        Issue Links

          Activity

          nicolas de loof created issue -
          nicolas de loof made changes -
          Field Original Value New Value
          Description Many maven plugins are wrapper around other tools. The plugin is designed for a version of the tool, and in many case user will want to use a specific version without having to patch the plugin. The <dependency> element on plugin configuration is a common way to do this, by overriding the plugin POM dependency with another version. This used to work with maven < 2.0.8

          In maven 2.0.8, this doesn't work anomire as the <dependency> set in plugin configuration is added to classpath, as a duplicate for the on declared by the plugin but LATER in the classpath.
          Many maven plugins are wrapper around other tools. The plugin is designed for a version of the tool, and in many case user will want to use a specific version without having to patch the plugin. The <dependency> element on plugin configuration is a common way to do this, by overriding the plugin POM dependency with another version.

          <plugin>
             <artifactId>castor-maven-plugin</artifactId>
             <dependencies>
                 <dependency>
                      <groupId>org.codehaus.castor</groupId>
                      <artifactId>castor</artifactId>
                      <version>VERSION OF CASTOR I WANT TO USE FOR CODE GENERATION</version>
                 </dependency>
             </dependencies>
          </plugin>

          This used to work with maven < 2.0.8

          In maven 2.0.8, this doesn't work anymore as the <dependency> set in plugin configuration is added to plugin classpath, as a duplicate for the one declared by the plugin but LATER in the classpath (but I may be wrong on this analysis).
          Hide
          Brett Porter added a comment -

          Hi nicolas - are you working on this yourself?

          If you have a test case, I'd like to ensure we get this in to 2.0.9.

          Show
          Brett Porter added a comment - Hi nicolas - are you working on this yourself? If you have a test case, I'd like to ensure we get this in to 2.0.9.
          Hide
          nicolas de loof added a comment -

          Yes, I plan to both provide a test case and investigate to fix this in 2.0.9.

          Show
          nicolas de loof added a comment - Yes, I plan to both provide a test case and investigate to fix this in 2.0.9.
          Hide
          nicolas de loof added a comment -

          testcase committed in maven\core-integration-testing\core-integration-tests
          testcase uses castor-maven-plugin as castor codegen includes castor version in generated files header
          on maven 2.0.8, generated code is always for 1.1.2.1, as specified by plugin dependencies, even when <dependency> is set on plugin configuration.

          Show
          nicolas de loof added a comment - testcase committed in maven\core-integration-testing\core-integration-tests testcase uses castor-maven-plugin as castor codegen includes castor version in generated files header on maven 2.0.8, generated code is always for 1.1.2.1, as specified by plugin dependencies, even when <dependency> is set on plugin configuration.
          Hide
          nicolas de loof added a comment -

          Use a LinkedHashSet to make plugin dependencies ordering predictable (same as maven 2.1) and place project.build.plugin.dependencies prior to plugin POM dependencies

          Show
          nicolas de loof added a comment - Use a LinkedHashSet to make plugin dependencies ordering predictable (same as maven 2.1) and place project.build.plugin.dependencies prior to plugin POM dependencies
          nicolas de loof made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 2.0.9 [ 13801 ]
          Resolution Fixed [ 1 ]
          Assignee nicolas de loof [ ndeloof ]
          Brian Fox made changes -
          Link This issue is duplicated by MNG-2972 [ MNG-2972 ]
          Hide
          Brian E. Fox added a comment -

          This issue causes MNG-3473. Reverting the change in v633014 causes the tests to pass.

          Show
          Brian E. Fox added a comment - This issue causes MNG-3473 . Reverting the change in v633014 causes the tests to pass.
          Brian Fox made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Brian Fox made changes -
          Link This issue relates to MNG-3473 [ MNG-3473 ]
          Hide
          Paul Benedict added a comment -

          I know MNG-3473 was reverted, but why since 2.0.9 is all about increasing stability? It seems, in my opinion, that these two should be solved together. If this is about timing, I don't see a critical need to push out 2.0.9 soon. Just my 2 cents.

          Show
          Paul Benedict added a comment - I know MNG-3473 was reverted, but why since 2.0.9 is all about increasing stability? It seems, in my opinion, that these two should be solved together. If this is about timing, I don't see a critical need to push out 2.0.9 soon. Just my 2 cents.
          Hide
          John Casey added a comment -

          The move to use LinkedHashSet was definitely correct IMO, but it led to some weird side effects for dependency ordering. I've gone back and added a pre-processing step using a LinkedHashMap to merge in the plugin-level dependencies and those from the plugin-POM itself. I kept the plugin-level deps as first to be added, which gives them precedence (so they can replace dependencies from the plugin POM), but added code to make sure any duplicates according to dependencyConflictId are avoided. This is consistent with dependencies in the POM, where duplicates there should lead to a model validation exception during project building.

          I think this issue can safely be put to bed now.

          Show
          John Casey added a comment - The move to use LinkedHashSet was definitely correct IMO, but it led to some weird side effects for dependency ordering. I've gone back and added a pre-processing step using a LinkedHashMap to merge in the plugin-level dependencies and those from the plugin-POM itself. I kept the plugin-level deps as first to be added, which gives them precedence (so they can replace dependencies from the plugin POM), but added code to make sure any duplicates according to dependencyConflictId are avoided. This is consistent with dependencies in the POM, where duplicates there should lead to a model validation exception during project building. I think this issue can safely be put to bed now.
          John Casey made changes -
          Assignee nicolas de loof [ ndeloof ] John Casey [ jdcasey ]
          Resolution Fixed [ 1 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          John Casey made changes -
          Link This issue relates to MNG-3119 [ MNG-3119 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 08:49:45 UTC 2015 [ 1428223785911 ]
          Mark Thomas made changes -
          Workflow jira [ 12713852 ] Default workflow, editable Closed status [ 12753620 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 21:45:26 UTC 2015 [ 1428270326204 ]
          Mark Thomas made changes -
          Workflow jira [ 12950604 ] Default workflow, editable Closed status [ 12986822 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          14h 57m 1 nicolas de loof 03/Mar/08 03:58
          Closed Closed Reopened Reopened
          17d 11h 3m 1 Brian Fox 20/Mar/08 15:01
          Reopened Reopened Closed Closed
          20h 3m 1 John Casey 21/Mar/08 11:05

            People

            • Assignee:
              John Casey
              Reporter:
              nicolas de loof
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development