Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-4453

[regression] Plugin versions defined in a lifecycle mapping are not respected

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0-alpha-4
    • Fix Version/s: 3.0-beta-1
    • Component/s: Plugins and Lifecycle
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      As reported by Sebastian Annies in Using a specific plugin version in custom lifecycle, the plugin version given by a lifecycle mapping like

      <verify>org.apache.maven.plugins:maven-source-plugin:2.1:jar-no-fork</verify>
      

      is not respected by Maven 3.0, it's preferring the version from the plugin management of the super POM instead.

        Activity

        Hide
        Sascha Scholz added a comment - - edited

        Benjamin's fix for Maven 3.0-beta-1 removes several (why not all?) plugins from the pluginManagement section in the Maven super POM. Instead, packaging type specific artifact handlers are used. But of course this is done only for 'core' packaging types. For others the latest plugin version is used (e.g. for nexus-plugin packaging type). I think that's a critical regression because not all builds are reproducable any more.

        Show
        Sascha Scholz added a comment - - edited Benjamin's fix for Maven 3.0-beta-1 removes several (why not all?) plugins from the pluginManagement section in the Maven super POM. Instead, packaging type specific artifact handlers are used. But of course this is done only for 'core' packaging types. For others the latest plugin version is used (e.g. for nexus-plugin packaging type). I think that's a critical regression because not all builds are reproducable any more.
        Hide
        Benjamin Bentmann added a comment -

        A build that relies on the super POM default versions is generally not reproducible unless one sticks to the proper Maven version having the expected plugin versions. There is only one way to achieve reproducibilty, specify the desired plugin versions in POMs under your control.

        Show
        Benjamin Bentmann added a comment - A build that relies on the super POM default versions is generally not reproducible unless one sticks to the proper Maven version having the expected plugin versions. There is only one way to achieve reproducibilty, specify the desired plugin versions in POMs under your control.
        Hide
        Sascha Scholz added a comment -

        Yes, that's exactly what I expect: Given a fixed Maven version the set of 'standard' plugins should be stable as it was intended with MNG-3395. With your recent patch that assumption isn't valid for every packaging type any more, right?

        Show
        Sascha Scholz added a comment - Yes, that's exactly what I expect: Given a fixed Maven version the set of 'standard' plugins should be stable as it was intended with MNG-3395 . With your recent patch that assumption isn't valid for every packaging type any more, right?
        Hide
        Benjamin Bentmann added a comment -

        The very point of this fix/patch was to make the lifecycle mapping introducing plugins responsible for their default versions, allowing a lifecycle mapping to work as intended by the author. Maven core continues to provide the versions for the built-in lifecycle mappings. But it still stands, relying on the default plugin versions from a particular Maven version is a bad practice.

        Show
        Benjamin Bentmann added a comment - The very point of this fix/patch was to make the lifecycle mapping introducing plugins responsible for their default versions, allowing a lifecycle mapping to work as intended by the author. Maven core continues to provide the versions for the built-in lifecycle mappings. But it still stands, relying on the default plugin versions from a particular Maven version is a bad practice.
        Hide
        Sascha Scholz added a comment -

        Ok. Where can I find an authoritative list of all 'standard'-plugins to configure them in my corporate parent's pluginManagement?

        Is it

        maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml
        maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml

        ?

        Show
        Sascha Scholz added a comment - Ok. Where can I find an authoritative list of all 'standard'-plugins to configure them in my corporate parent's pluginManagement? Is it maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/artifact-handlers.xml maven/maven-3/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml ?

          People

          • Assignee:
            Benjamin Bentmann
            Reporter:
            Benjamin Bentmann
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: