Maven
  1. Maven
  2. MNG-3426

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

    Details

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

      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 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 -
          Fix Version/s 2.0.9 [ 13801 ]
          Assignee nicolas de loof [ ndeloof ]
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          brianfox brianfox made changes -
          Link This issue is duplicated by MNG-2972 [ MNG-2972 ]
          Hide
          brianfox brianfox added a comment -

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

          Show
          brianfox brianfox added a comment - This issue causes MNG-3473 . Reverting the change in v633014 causes the tests to pass.
          brianfox brianfox made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          brianfox brianfox 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 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          John Casey made changes -
          Link This issue relates to MNG-3119 [ MNG-3119 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: