Maven 2 & 3

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

This issue is duplicated by:
MNG-5088 The order of plugins within the same phase cannot be specified in Maven 3 Major Closed
This issue relates to:
MNG-5090 Maven End Users should be able to control the execution order of plugins without creating a custom Lifecycle and Package Type Major Closed
This issue is related to:
MNG-2784 Multiple executions of the same plugin at the same life cycle phase in a multi-module profile mixed up Critical Closed
MNG-3719 [regression] plugin execution ordering no longer POM ordered in 2.0.9 Critical Closed
MNG-1994 Execution order of child plugins is arbitrary if inheritance is involved Critical Closed
MNG-4341 [regression] Plugins are not executed in POM order Major Closed
MNG-4727 Allow ordering plugin execution via <id/> Major Closed
This issue is superceded by:
MNG-1412 dependency sorting in classpath Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
John Casey added a comment -

See MNG-2784

Show
John Casey added a comment - See MNG-2784
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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.

People

Vote (83)
Watch (71)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.