Wrong execution order of plugins in same phase

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

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.

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.

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

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

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.

Maybe you should also have a look at MNG-2784

See MNG-2784

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.

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

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

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

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.

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).

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

I Agree. This bug is not fixed in 2.2.0.

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

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

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

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" ?

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.

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

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.

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.

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

Hi,

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

Does anyone have a workaround?

@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>

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

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.

@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...

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.

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.

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.

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

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.

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.

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

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

@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.

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

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

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