Maven
  1. Maven
  2. MNG-4453

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

    Details

    • Type: Bug Bug
    • Status: 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

      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
        Brian E. Fox added a comment -

        Personally I didn't even know you could put a version into the lifecycle, I've never seen that done.

        Second, I always subscribe to the theory that "closest" wins. In the inheritance case, it means things in my pom override my parent pom, which overrides the grandparent etc. I think in this case, the pom is "closer" than the lifecycle and therefore it should win as is happening in the 3.x case. In otherwords, if I use a lifecycle that defines a version but need to tweak the version how would I do it? The pom is my only vechicle for overriding it.

        Show
        Brian E. Fox added a comment - Personally I didn't even know you could put a version into the lifecycle, I've never seen that done. Second, I always subscribe to the theory that "closest" wins. In the inheritance case, it means things in my pom override my parent pom, which overrides the grandparent etc. I think in this case, the pom is "closer" than the lifecycle and therefore it should win as is happening in the 3.x case. In otherwords, if I use a lifecycle that defines a version but need to tweak the version how would I do it? The pom is my only vechicle for overriding it.
        Hide
        Paul Benedict added a comment - - edited

        Second, I always subscribe to the theory that "closest" wins.

        It's more than a theory. It's documented on Maven's web site it's the only dependency resolution strategy currently supported.

        Show
        Paul Benedict added a comment - - edited Second, I always subscribe to the theory that "closest" wins. It's more than a theory. It's documented on Maven's web site it's the only dependency resolution strategy currently supported.
        Hide
        Brian E. Fox added a comment -

        I wasn't referring to dependency resolution strategies here. The closest theory applies to many things Maven does, particularly inheritence:

        My pom is closer than my parent.
        My parent is closer than my grandparent.
        My grandparent is closer than my corporate pom.
        My corporate pom is closer than the super pom.

        Above logically represents my "effective pom".

        I'm asserting that the "effective pom" is closer than the lifecycle version definition as it applies to this issue.

        Show
        Brian E. Fox added a comment - I wasn't referring to dependency resolution strategies here. The closest theory applies to many things Maven does, particularly inheritence: My pom is closer than my parent. My parent is closer than my grandparent. My grandparent is closer than my corporate pom. My corporate pom is closer than the super pom. Above logically represents my "effective pom". I'm asserting that the "effective pom" is closer than the lifecycle version definition as it applies to this issue.
        Hide
        Paul Benedict added a comment - - edited

        Brian, to your question "how would I do it"? If dependency management can't alter it, what can? After thinking about it, I would agree that the POM plugin management should be able to override.

        Show
        Paul Benedict added a comment - - edited Brian, to your question "how would I do it"? If dependency management can't alter it, what can? After thinking about it, I would agree that the POM plugin management should be able to override.
        Hide
        Benjamin Bentmann added a comment -

        Fixed in r932609.

        Show
        Benjamin Bentmann added a comment - Fixed in r932609 .
        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:

              Development