Maven
  1. Maven
  2. MNG-2258

Wrong execution order of plugins in same phase

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 3.0.3
    • Component/s: None
    • Labels:
      None
    • Environment:
      N/A
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      AFAIK plugins should be execute in the same order as they are listed in the POM, when bound to the same phase. This does not happen, the execution order is arbitrary.

        Issue Links

          Activity

          Hide
          Fredrik Vraalsen added a comment -

          I'm having the same problem. I need to run two plugins in the generate-sources phase, where one depends on the output of the other.

          For more information, please see http://www.nabble.com/Plugin-execution-order-within-lifecycle-phase-t1541372.html#a4187121

          Show
          Fredrik Vraalsen added a comment - I'm having the same problem. I need to run two plugins in the generate-sources phase, where one depends on the output of the other. For more information, please see http://www.nabble.com/Plugin-execution-order-within-lifecycle-phase-t1541372.html#a4187121
          Hide
          David Hay added a comment -

          I'd actually rate this much higher priority. I've already run into this limitation several times during the development of my project. In particular, I want to run the dependency-maven-plugin:copy followed by the assembly plugin. But maven wants to run them in the opposite order, which doesn't work very well.

          I've also wanted to run the hibernate3-plugin to generate my DDL followed by an antrun plugin to load some sample data, but I can't be assured that the plugins will run in that order.

          Show
          David Hay added a comment - I'd actually rate this much higher priority. I've already run into this limitation several times during the development of my project. In particular, I want to run the dependency-maven-plugin:copy followed by the assembly plugin. But maven wants to run them in the opposite order, which doesn't work very well. I've also wanted to run the hibernate3-plugin to generate my DDL followed by an antrun plugin to load some sample data, but I can't be assured that the plugins will run in that order.
          Hide
          Martin Zeltner added a comment -

          I'd rate this issue much higher too. I've already solved the order problem with dependencies (see MNG-1412) and this issue can be solved equivalently.

          Show
          Martin Zeltner added a comment - I'd rate this issue much higher too. I've already solved the order problem with dependencies (see MNG-1412 ) and this issue can be solved equivalently.
          Hide
          Brian Topping added a comment -

          Same problem here. It's possible to make a new goal on a mojo so that one contains another, but there's no other way to get them to cleanly execute in order.

          Show
          Brian Topping added a comment - Same problem here. It's possible to make a new goal on a mojo so that one contains another, but there's no other way to get them to cleanly execute in order.
          Hide
          Martin Zeltner added a comment -

          BTW the patches appended to MNG-1412 does also solve the execution order problem of plugins. It does solve the order problem for all artifacts! Until today the HashSets and HashMaps where not replaced by LinkedHashSets and LinkedHashMaps (see SVN repo). I don't understand why commiters from these Maven 2 components don't apply the patches for such an important issue. I would help if I had commit rights but right now i can just watch and claim.

          Cheers,
          Martin
          http://el4j.sf.net

          Show
          Martin Zeltner added a comment - BTW the patches appended to MNG-1412 does also solve the execution order problem of plugins. It does solve the order problem for all artifacts! Until today the HashSets and HashMaps where not replaced by LinkedHashSets and LinkedHashMaps (see SVN repo). I don't understand why commiters from these Maven 2 components don't apply the patches for such an important issue. I would help if I had commit rights but right now i can just watch and claim. Cheers, Martin http://el4j.sf.net
          Hide
          Brian Topping added a comment -

          Great observation Martin! I marked this as superceded by that bug.

          Show
          Brian Topping added a comment - Great observation Martin! I marked this as superceded by that bug.
          Hide
          Sebastian Davids added a comment -

          This bug should be solved independent of MNG-1412.

          This is a serious defect.

          Considering the high number of votes and watchers it is important to a lot of people.

          It should be backported to 2.0.x stream.

          After that a new 2.0.x release should be made.

          Having to wait over one year for a simple HashSet -> LinkedHashSet and HashMap -> LinkedHashMap replacement is ridiculous.

          Even more so, considering that a patch has been supplied over half a year ago.

          @@ Use Case @@

          <project ...>
          ...
          <modules>
          <module>ejb</module>
          <module>war</module>
          </modules>
          ...
          <build>
          ...
          <plugins>
          <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <inherited>false</inherited>
          <executions>
          <execution>
          <phase>install</phase>
          <configuration>
          <tasks>
          ... deploy to server ...
          </tasks>
          </configuration>
          <goals>
          <goal>run</goal>
          </goals>
          </execution>
          </executions>
          </plugin>
          </plugins>
          ...
          </build>
          ...
          </project>

          Let's say "ejb" contains EJB stuff and "war" contains the web application; "war" depends on "ejb"; and both are children of a parent POM, so that the generated "ejb" JAR gets packaged into the WAR.

          Now we want to be able to use "install" to deploy the created WAR to the server (yes, there's Cargo, but it does not support all JEE containers, yet.)

          We have to set <inherited>false</inherited> so Maven won't run the deployment for "ejb" and "war".

          But it does not work because "maven-antrun-plugin" is run before the children ("ejb" and "war") are run.

          Show
          Sebastian Davids added a comment - This bug should be solved independent of MNG-1412 . This is a serious defect. Considering the high number of votes and watchers it is important to a lot of people. It should be backported to 2.0.x stream. After that a new 2.0.x release should be made. Having to wait over one year for a simple HashSet -> LinkedHashSet and HashMap -> LinkedHashMap replacement is ridiculous. Even more so, considering that a patch has been supplied over half a year ago. @@ Use Case @@ <project ...> ... <modules> <module>ejb</module> <module>war</module> </modules> ... <build> ... <plugins> <plugin> <artifactId>maven-antrun-plugin</artifactId> <inherited>false</inherited> <executions> <execution> <phase>install</phase> <configuration> <tasks> ... deploy to server ... </tasks> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> </plugins> ... </build> ... </project> Let's say "ejb" contains EJB stuff and "war" contains the web application; "war" depends on "ejb"; and both are children of a parent POM, so that the generated "ejb" JAR gets packaged into the WAR. Now we want to be able to use "install" to deploy the created WAR to the server (yes, there's Cargo, but it does not support all JEE containers, yet.) We have to set <inherited>false</inherited> so Maven won't run the deployment for "ejb" and "war". But it does not work because "maven-antrun-plugin" is run before the children ("ejb" and "war") are run.
          Hide
          Maik Ebert added a comment -

          Maybe you should also have a look at MNG-2784

          Show
          Maik Ebert added a comment - Maybe you should also have a look at MNG-2784
          Hide
          John Casey added a comment -
          Show
          John Casey added a comment - See MNG-2784
          Hide
          Viktor Nordling added a comment -

          It seems that this issue is not actually resolved. The fix version is set to 2.1, but if I am not mistaken, 2.1 has not been released yet?

          Since we need this issue to be fixed for our project, I would be happy if it could be reopened.

          Show
          Viktor Nordling added a comment - It seems that this issue is not actually resolved. The fix version is set to 2.1, but if I am not mistaken, 2.1 has not been released yet? Since we need this issue to be fixed for our project, I would be happy if it could be reopened.
          Hide
          Andrew Robinson added a comment -

          This is a blocking issue, why is it being left to 2.1?

          Show
          Andrew Robinson added a comment - This is a blocking issue, why is it being left to 2.1?
          Hide
          Sandra Bogaert added a comment -

          Hi,
          What about this issue ?
          Do you have a release date ?
          Thanks in advance

          Show
          Sandra Bogaert added a comment - Hi, What about this issue ? Do you have a release date ? Thanks in advance
          Hide
          David Haccoun added a comment -

          Hi,

          This bug is always present in the 2.1 version.
          On the state of this issue, we can see that is closed. The reason : Duplicate.
          But where is the reference of the duplicated issue ?

          Cheers,
          David

          Show
          David Haccoun added a comment - Hi, This bug is always present in the 2.1 version. On the state of this issue, we can see that is closed. The reason : Duplicate. But where is the reference of the duplicated issue ? Cheers, David
          Hide
          John Casey added a comment -

          possible lingering problem with this issue, which (hopefully) will be different from MNG-3719. I'll re-close as duplicate if we can't tease out some more details and a test case for this issue, since there is no hope of reliably fixing the issue if we can't reproduce it.

          Show
          John Casey added a comment - possible lingering problem with this issue, which (hopefully) will be different from MNG-3719 . I'll re-close as duplicate if we can't tease out some more details and a test case for this issue, since there is no hope of reliably fixing the issue if we can't reproduce it.
          Hide
          John Casey added a comment -

          Re-closing as duplicate since there hasn't been any sort of update on the ongoing reports of problems. We can come back to this in the next release if there is still a problem (other than the problem of a limited lifecycle vocabulary, that is).

          Show
          John Casey added a comment - Re-closing as duplicate since there hasn't been any sort of update on the ongoing reports of problems. We can come back to this in the next release if there is still a problem (other than the problem of a limited lifecycle vocabulary, that is).
          Hide
          Jayesh Lalwani added a comment -

          Just tried this issue in with 2.2 and doesn't look like it's fixed. The pom has a profile with 4 plugins in the following order
          a) SQL-maven plugin. This plugin drops the database
          b) hibernate3-maven-plugin :- this creates the database schema
          c) dbunit-maven-plugin: populates the data with some test data
          d) SQL-maven plugin:- Adds some more test data to the database

          All ther executions are tied to process-test-resources phase.

          Maven executes the plugins in order a, d, b, c, instead of a, b, c, d

          Show
          Jayesh Lalwani added a comment - Just tried this issue in with 2.2 and doesn't look like it's fixed. The pom has a profile with 4 plugins in the following order a) SQL-maven plugin. This plugin drops the database b) hibernate3-maven-plugin :- this creates the database schema c) dbunit-maven-plugin: populates the data with some test data d) SQL-maven plugin:- Adds some more test data to the database All ther executions are tied to process-test-resources phase. Maven executes the plugins in order a, d, b, c, instead of a, b, c, d
          Hide
          Justin K added a comment -

          I Agree. This bug is not fixed in 2.2.0.

          Show
          Justin K added a comment - I Agree. This bug is not fixed in 2.2.0.
          Hide
          Wendy Smoak added a comment -

          Reopening based on comments. Can someone clarify the expected behavior and point to docs/tests which explain it?

          Show
          Wendy Smoak added a comment - Reopening based on comments. Can someone clarify the expected behavior and point to docs/tests which explain it?
          Hide
          Wendy Smoak added a comment -

          Un-setting fix version (was 2.2.0) as it was marked as a duplicate and it's not clear it was ever fixed...

          Show
          Wendy Smoak added a comment - Un-setting fix version (was 2.2.0) as it was marked as a duplicate and it's not clear it was ever fixed...
          Hide
          Benjamin Bentmann added a comment -

          Could one of the reporters attach a working example POM to reproduce this?

          Show
          Benjamin Bentmann added a comment - Could one of the reporters attach a working example POM to reproduce this?
          Hide
          E K added a comment -

          Maven is grouping executions of same plugin at same phase without checking whether there is/are execution(s) of another plugin(s) in between or not in the pom file.

          And this cause the execution order specified by Jayesh Lalwani. A dummy project is attached if it is necessary to see the problem.
          Suggested solution by John Casey on MNG-3719 is to use different phases for execution of same plug-in.

          Is this going to be fixed or should we follow suggested "cheating" ?

          Show
          E K added a comment - Maven is grouping executions of same plugin at same phase without checking whether there is/are execution(s) of another plugin(s) in between or not in the pom file. And this cause the execution order specified by Jayesh Lalwani. A dummy project is attached if it is necessary to see the problem. Suggested solution by John Casey on MNG-3719 is to use different phases for execution of same plug-in. Is this going to be fixed or should we follow suggested "cheating" ?
          Hide
          John Casey added a comment -

          Re-specifying the same plugin in two different XML blocks of the build section within the same POM (without using profiles) is NOT valid. This is a recipe for disaster. If users must replicate any new configurations across multiple plugin sections just to get consistent behavior for all mojos in a plugin, this will cause massive confusion.

          I do agree that we should detect this scenario and fail with a validation error, so I'm not going to close this issue yet. But if you want two mojo executions from the same plugin to happen before and after another mojo from another plugin, you must assign them to different phases to arrange this.

          Show
          John Casey added a comment - Re-specifying the same plugin in two different XML blocks of the build section within the same POM (without using profiles) is NOT valid. This is a recipe for disaster. If users must replicate any new configurations across multiple plugin sections just to get consistent behavior for all mojos in a plugin, this will cause massive confusion. I do agree that we should detect this scenario and fail with a validation error, so I'm not going to close this issue yet. But if you want two mojo executions from the same plugin to happen before and after another mojo from another plugin, you must assign them to different phases to arrange this.
          Hide
          Hrotkó Gábor added a comment - - edited

          I am not a big maven guru, but we have this problem now with 2.2.1

          My breaf description is this:
          the first transitive dependency version will win

          ...
          <dependency> <!-- has a dependency on myModul_X-1.0 -->
              <groupId>myCompany.myType</groupId>
              <artifactId>myModul_B</artifactId>
              <version>1.0</version>
              <type>myType</type>
          </dependency>
          <dependency> <!-- has a dependency on myModul_X-1.2 -->
              <groupId>myCompany.myType</groupId>
              <artifactId>myModul_A</artifactId>
              <version>1.0</version>
              <type>myType</type>
          </dependency>   
          ...
          

          after the build, myModul_X-1.0 will be included
          ...
          [DEBUG] myCompany.myType:myModul_A:myType:1.0:compile (selected for compile)
          [DEBUG] myCompany.myType:myModul_X:myType:1.2:compile (removed - nearer found: 1.0)
          ...

          but when myModul_A is the first in the pom:

          ...
          <dependency> <!-- has a dependency on myModul_X-1.2 -->
              <groupId>myCompany.myType</groupId>
              <artifactId>myModul_A</artifactId>
              <version>1.0</version>
              <type>myType</type>
          </dependency>  
          <dependency> <!-- has a dependency on myModul_X-1.0 -->
              <groupId>myCompany.myType</groupId>
              <artifactId>myModul_B</artifactId>
              <version>1.0</version>
              <type>myType</type>
          </dependency>
          ...
          

          after the build, myModul_X-1.2 will be included

          ...
          [DEBUG] myCompany.myType:myModul_X:myType:1.0:compile (removed - nearer found: 1.2)
          ...

          additional info:
          it worked ok with 2.0.8 , but not since 2.0.9

          Show
          Hrotkó Gábor added a comment - - edited I am not a big maven guru, but we have this problem now with 2.2.1 My breaf description is this: the first transitive dependency version will win ... <dependency> <!-- has a dependency on myModul_X-1.0 --> <groupId> myCompany.myType </groupId> <artifactId> myModul_B </artifactId> <version> 1.0 </version> <type> myType </type> </dependency> <dependency> <!-- has a dependency on myModul_X-1.2 --> <groupId> myCompany.myType </groupId> <artifactId> myModul_A </artifactId> <version> 1.0 </version> <type> myType </type> </dependency> ... after the build, myModul_X-1.0 will be included ... [DEBUG] myCompany.myType:myModul_A:myType:1.0:compile (selected for compile) [DEBUG] myCompany.myType:myModul_X:myType:1.2:compile (removed - nearer found: 1.0) ... but when myModul_A is the first in the pom: ... <dependency> <!-- has a dependency on myModul_X-1.2 --> <groupId> myCompany.myType </groupId> <artifactId> myModul_A </artifactId> <version> 1.0 </version> <type> myType </type> </dependency> <dependency> <!-- has a dependency on myModul_X-1.0 --> <groupId> myCompany.myType </groupId> <artifactId> myModul_B </artifactId> <version> 1.0 </version> <type> myType </type> </dependency> ... after the build, myModul_X-1.2 will be included ... [DEBUG] myCompany.myType:myModul_X:myType:1.0:compile (removed - nearer found: 1.2) ... additional info: it worked ok with 2.0.8 , but not since 2.0.9
          Hide
          Benjamin Bentmann added a comment -

          Hrotkó, the dependency resolution works as designed, cf. Introduction to the Dependency Mechanism. If you don't want to rely on the nearest-/first-wins strategy for conflict resolution, you can use <dependencyManagement> to control the versions of the transitive dependencies.

          Show
          Benjamin Bentmann added a comment - Hrotkó, the dependency resolution works as designed, cf. Introduction to the Dependency Mechanism . If you don't want to rely on the nearest-/first-wins strategy for conflict resolution, you can use <dependencyManagement> to control the versions of the transitive dependencies.
          Hide
          Julien HENRY added a comment - - edited

          In my corporate parent pom I have the following in reporting section:

          <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-jxr-plugin</artifactId>
              <version>2.1</version>
          </plugin>
           ...
          <plugin>
              <groupId>org.codehaus.mojo</groupId>
              <artifactId>taglist-maven-plugin</artifactId>
              <version>2.4</version>
          </plugin>
          

          (in this order)

          Then I have create a sample test project from Maven quickstart archetype but:

          >mvn clean install site
          ...
          [INFO] Generating "Tag List" report.
          [ERROR] Taglist plugin MUST be executed after the JXR plugin.  No links to xref were generated.
          [WARNING] Unable to locate Source XRef to link to - DISABLED
          

          Looking at the log I can see reporting plugins are generated in an order completely different of the reporting section order.

          Show
          Julien HENRY added a comment - - edited In my corporate parent pom I have the following in reporting section: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-jxr-plugin </artifactId> <version> 2.1 </version> </plugin> ... <plugin> <groupId> org.codehaus.mojo </groupId> <artifactId> taglist-maven-plugin </artifactId> <version> 2.4 </version> </plugin> (in this order) Then I have create a sample test project from Maven quickstart archetype but: >mvn clean install site ... [INFO] Generating "Tag List" report. [ERROR] Taglist plugin MUST be executed after the JXR plugin. No links to xref were generated. [WARNING] Unable to locate Source XRef to link to - DISABLED Looking at the log I can see reporting plugins are generated in an order completely different of the reporting section order.
          Hide
          Martin Zeltner added a comment -

          Hi Julien

          Are you sure that you're using Maven 2.2.1, the newest one? All previous version where for trash, when you where going into "details", like the execution order in one phase. Also the current version needs still some fine tuning, that I'm currently working out.

          Cheers
          Martin

          Show
          Martin Zeltner added a comment - Hi Julien Are you sure that you're using Maven 2.2.1, the newest one? All previous version where for trash, when you where going into "details", like the execution order in one phase. Also the current version needs still some fine tuning, that I'm currently working out. Cheers Martin
          Hide
          wargre added a comment -

          Hi,

          i've got same issue as Julien with 2.2.1 version.

          Does anyone have a workaround?

          Show
          wargre added a comment - Hi, i've got same issue as Julien with 2.2.1 version. Does anyone have a workaround?
          Hide
          Pablo added a comment -

          @wargre: My workaround is to run JXR twice:

          • first time in the pre-site phase (with the POM snippet below), so you're sure it's done before the rest.
          • second time in the standard reporting section, so you get the XREF links in the site menu.
          <build>
            <plugins>
              <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jxr-plugin</artifactId>
                <executions>
                  <execution>
                    <id>jxr-pre-site</id>
                    <phase>pre-site</phase>
                    <goals>
                      <goal>jxr</goal>
                      <goal>test-jxr</goal>
                    </goals>
                  </execution>
                </executions>
              </plugin>
            </plugins>
          </build>
          
          Show
          Pablo added a comment - @wargre: My workaround is to run JXR twice: first time in the pre-site phase (with the POM snippet below), so you're sure it's done before the rest. second time in the standard reporting section, so you get the XREF links in the site menu. <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jxr-plugin</artifactId> <executions> <execution> <id>jxr-pre-site</id> <phase>pre-site</phase> <goals> <goal>jxr</goal> <goal>test-jxr</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
          Hide
          wargre added a comment -

          funny thing is adding an execution in pre-site made another reporting plugin ordering.

          Show
          wargre added a comment - funny thing is adding an execution in pre-site made another reporting plugin ordering.
          Hide
          Daniel Zardi Fernandes added a comment - - edited

          I found this bug while looking for a solution to the taglist-maven-plugin issue with the maven-jxr-plugin, so I have no knowledge about the execution order bug, but I managed to get the taglist plugin working without a second run of jxr.

          I noticed that when running jxr in the pre-site phase the output where generated in the reports directory, not in the site directory, so it's probably an issue of the taglist-maven-plugin.

          Try adding the following to the taglist-maven-plugin configuration, it worked for me (don't forget to change the directories to match your configuration if needed).

          <xrefLocation>target/site/xref</xrefLocation>
          <testXrefLocation>target/site/xref-test</testXrefLocation>
          

          Probably it won't help with this bug, but it's a better workaround than running jxr twice.

          By the way, I'm using Maven 2.2.1 and got the "Taglist plugin MUST be executed after the JXR plugin." message too.

          Show
          Daniel Zardi Fernandes added a comment - - edited I found this bug while looking for a solution to the taglist-maven-plugin issue with the maven-jxr-plugin, so I have no knowledge about the execution order bug, but I managed to get the taglist plugin working without a second run of jxr. I noticed that when running jxr in the pre-site phase the output where generated in the reports directory, not in the site directory, so it's probably an issue of the taglist-maven-plugin. Try adding the following to the taglist-maven-plugin configuration, it worked for me (don't forget to change the directories to match your configuration if needed). <xrefLocation> target/site/xref </xrefLocation> <testXrefLocation> target/site/xref-test </testXrefLocation> Probably it won't help with this bug, but it's a better workaround than running jxr twice. By the way, I'm using Maven 2.2.1 and got the "Taglist plugin MUST be executed after the JXR plugin." message too.
          Hide
          Sebastian Paul added a comment -

          @Daniel: How did you work around this issue without running jxr twice? I am using Maven 2.2.1 too, and have the same issue. When jxr only runs once in pre-site, the report does not contain a link to the source (Reports section in the navigation area). Only the tag list plugin correctly links to the source...

          Show
          Sebastian Paul added a comment - @Daniel: How did you work around this issue without running jxr twice? I am using Maven 2.2.1 too, and have the same issue. When jxr only runs once in pre-site, the report does not contain a link to the source (Reports section in the navigation area). Only the tag list plugin correctly links to the source...
          Hide
          Laird Nelson added a comment -

          This bug is still present in Maven 2.2.1.

          My project runs a goal from maven-dependency-plugin, maven-resources-plugin and maven-jar-plugin during the prepare-package phase.

          These are listed in that order.

          They are executed in an arbitrary order.

          Show
          Laird Nelson added a comment - This bug is still present in Maven 2.2.1. My project runs a goal from maven-dependency-plugin, maven-resources-plugin and maven-jar-plugin during the prepare-package phase. These are listed in that order. They are executed in an arbitrary order.
          Hide
          Benjamin Bentmann added a comment -

          I just got aware of the fact that inheritance (and probably profile injection) has a rather counterintuitive effect on the plugin order in the POM. The plugin order given by a parent POM is dominant over the plugin order in a child POM. This circumstance might add to the observation that the POM order (as given in the current child project) is not respected.

          Show
          Benjamin Bentmann added a comment - I just got aware of the fact that inheritance (and probably profile injection) has a rather counterintuitive effect on the plugin order in the POM. The plugin order given by a parent POM is dominant over the plugin order in a child POM. This circumstance might add to the observation that the POM order (as given in the current child project) is not respected.
          Hide
          Benson Margulies added a comment -

          The original problem reported in the original test case is fixed in 3.0.3. There is much other material in here, but if someone claims that it amounts to a defect, they can make a distinct JIRA with a test case to that effect.

          Show
          Benson Margulies added a comment - The original problem reported in the original test case is fixed in 3.0.3. There is much other material in here, but if someone claims that it amounts to a defect, they can make a distinct JIRA with a test case to that effect.
          Hide
          Graham Lea added a comment -

          Please consider reviewing MNG-3522 and MNG-5090 as examples of distinct JIRAs with test cases that are not resovled in 3.0.3.

          Show
          Graham Lea added a comment - Please consider reviewing MNG-3522 and MNG-5090 as examples of distinct JIRAs with test cases that are not resovled in 3.0.3.
          Hide
          Benson Margulies added a comment -

          I ran the test case and it executed in the right order with 3.0.3. I don't know what to suggest if that's not happening for you.

          Show
          Benson Margulies added a comment - I ran the test case and it executed in the right order with 3.0.3. I don't know what to suggest if that's not happening for you.
          Hide
          Scott Glajch added a comment - - edited

          I'm not sure if this warrants reopening this bug or a new bug (or hopefully I'm missing something and just doing it wrong), but I think a slightly more complicated version of this use case is failing for us.

          We are using 3.0.3 and in general, the ordering of plugins with the same lifecycle phase is consistent to the order they were declared in the pom. However it appears that once we add another plugin execution for the same plugin type and the same lifecycle in a parent pom, the ordering gets screwed up.

          Our pom has 3 plugins executing during the "prepare-package" lifecycle currently. They are (in order of declaration in the pom):
          maven-war-plugin:2.2.rsa3:exploded (default)
          maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default)
          gmaven-plugin:1.3:execute (perform xslt transformation)

          They execute in the correct order. Then, in the parent pom for our projects we added this to the "prepare-package" lifecycle:
          gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml)

          Now when our project runs, the plugins get executed in this order:

          maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default)
          gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml)
          gmaven-plugin:1.3:execute (perform xslt transformation)

          I don't know if the fourth goal (the war plugin goal) ever gets executed because the build fails during "perform xslt transformation" because it is relying on the war goal to run first.

          I would hazard a guess that the problem has to do with either inserting plugin executions from a parent project, or the combination of that and the fact that the same plugin was defined in both the current and parent project. The ordering logic might never have taken this into account because you're not allowed to define the same plugin twice within the same pom file.

          Show
          Scott Glajch added a comment - - edited I'm not sure if this warrants reopening this bug or a new bug (or hopefully I'm missing something and just doing it wrong), but I think a slightly more complicated version of this use case is failing for us. We are using 3.0.3 and in general, the ordering of plugins with the same lifecycle phase is consistent to the order they were declared in the pom. However it appears that once we add another plugin execution for the same plugin type and the same lifecycle in a parent pom, the ordering gets screwed up. Our pom has 3 plugins executing during the "prepare-package" lifecycle currently. They are (in order of declaration in the pom): maven-war-plugin:2.2.rsa3:exploded (default) maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (perform xslt transformation) They execute in the correct order. Then, in the parent pom for our projects we added this to the "prepare-package" lifecycle: gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) Now when our project runs, the plugins get executed in this order: maven-rsa-generate-resource-bundles-plugin:1.21:process-product-conditional-files (default) gmaven-plugin:1.3:execute (add-p4-variable-to-rebel-xml) gmaven-plugin:1.3:execute (perform xslt transformation) I don't know if the fourth goal (the war plugin goal) ever gets executed because the build fails during "perform xslt transformation" because it is relying on the war goal to run first. I would hazard a guess that the problem has to do with either inserting plugin executions from a parent project, or the combination of that and the fact that the same plugin was defined in both the current and parent project. The ordering logic might never have taken this into account because you're not allowed to define the same plugin twice within the same pom file.
          Hide
          Derrick Isaacson added a comment -

          I'm seeing the same issue as Scott in a project.

          Show
          Derrick Isaacson added a comment - I'm seeing the same issue as Scott in a project.
          Hide
          Hendy Irawan added a comment -

          This bug isn't fixed yet. I'm using Maven 3.0.4 and the ordering is still arbitrary

          Show
          Hendy Irawan added a comment - This bug isn't fixed yet. I'm using Maven 3.0.4 and the ordering is still arbitrary
          Hide
          Barrie Treloar added a comment -

          @Scott
          I'd suggest filing a new bug and reference this one.
          Test cases (and a patch) will make your chances of getting this fixed a lot higher.

          @Hendy
          See comment to Scott.

          Show
          Barrie Treloar added a comment - @Scott I'd suggest filing a new bug and reference this one. Test cases (and a patch) will make your chances of getting this fixed a lot higher. @Hendy See comment to Scott.
          Hide
          Hendy Irawan added a comment -

          Thank you Barrie.

          I tried to reproduce the problem but it seems Maven 3.0.4 is fine! (yaay

          The problem seems to be in a thirdparty plugin, org.apache.karaf.tooling : features-maven-plugin : generate-features-xml.

          For those curious, or want to test, the testcase is in : https://github.com/ceefour/generate-features-xml-bug

          Related bug : https://issues.apache.org/jira/browse/KARAF-1681

          Show
          Hendy Irawan added a comment - Thank you Barrie. I tried to reproduce the problem but it seems Maven 3.0.4 is fine! (yaay The problem seems to be in a thirdparty plugin, org.apache.karaf.tooling : features-maven-plugin : generate-features-xml. For those curious, or want to test, the testcase is in : https://github.com/ceefour/generate-features-xml-bug Related bug : https://issues.apache.org/jira/browse/KARAF-1681
          Hide
          Hendy Irawan added a comment -

          MNG-2258 should already be fixed, tested with maven 3.0.4

          Show
          Hendy Irawan added a comment - MNG-2258 should already be fixed, tested with maven 3.0.4
          Hide
          Eric Sirianni added a comment -

          @Scott - I am observing the same behavior. Have you filed the new bug?

          Show
          Eric Sirianni added a comment - @Scott - I am observing the same behavior. Have you filed the new bug?
          Hide
          Karsten Gresch added a comment -

          As per my tests, this unpleasant bug still exists for 3.04 and 3.05. Tested with maven-jar-plugin, maven-assembly-plugin and copy-maven-plugin, all executed in phase 'package'.

          Perhaps it's a bug in the latter plugin though it seems to me that it is very well crafted (despite the artifact naming perhaps).

          I just don't have the time getting into Maven internal's to change the execution mechanism, but as per my opinion, Maven should control the execution order and no plugin should be able to break out from Maven's control.

          Anyway - very, very unpleasant. The only workaround I see when not creating pseudo-projects for dependent packaging executions is creating multiple profiles and calling them in the correct order.

          Could somebody please open this ticket again? From my point of view, specifying the execution order is quite important in the packaging phase and if Maven's goal is supporting the entire development lifecycle, it must support this.

          Cheers,

          Karsten

          Twitter: @gresch

          Show
          Karsten Gresch added a comment - As per my tests, this unpleasant bug still exists for 3.04 and 3.05. Tested with maven-jar-plugin, maven-assembly-plugin and copy-maven-plugin, all executed in phase 'package'. Perhaps it's a bug in the latter plugin though it seems to me that it is very well crafted (despite the artifact naming perhaps). I just don't have the time getting into Maven internal's to change the execution mechanism, but as per my opinion, Maven should control the execution order and no plugin should be able to break out from Maven's control. Anyway - very, very unpleasant. The only workaround I see when not creating pseudo-projects for dependent packaging executions is creating multiple profiles and calling them in the correct order. Could somebody please open this ticket again? From my point of view, specifying the execution order is quite important in the packaging phase and if Maven's goal is supporting the entire development lifecycle, it must support this. Cheers, Karsten Twitter: @gresch
          Hide
          Alessandro Dionisi added a comment -

          Yes I confirm that. It also happen for me in assembly-plugin.

          Show
          Alessandro Dionisi added a comment - Yes I confirm that. It also happen for me in assembly-plugin.

            People

            • Assignee:
              Benson Margulies
              Reporter:
              David J. M. Karlsen
            • Votes:
              83 Vote for this issue
              Watchers:
              75 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: