History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: MNG-1994
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Critical Critical
Assignee: Unassigned
Reporter: John Didion
Votes: 17
Watchers: 10
Operations

If you were logged in you would be able to see more operations.
Maven 2

Execution order of child plugins is arbitrary if inheritance is involved

Created: 19/Jan/06 05:25 PM   Updated: 12/Jun/08 05:51 PM
Component/s: Inheritance and Interpolation
Affects Version/s: 2.0.1
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Text File mergePluginLists.txt (3 kb)

Issue Links:
Related
 

Complexity: Intermediate
Patch Submitted: Yes


 Description  « Hide
This is related to MNG-1499, but different, and, in my opinion, equally important. It makes sense that the order of plugin execution should be the same as it appears in the POM. For example, I have two plugins: one that generates a batch file and one that executes it. These plugins must run in order or the build will fail. However, the current implementation of ModelUtils.mergePluginLists does not respect the order of child plugins.

There is also a seperate bug in that the assembledPlugins map is being checked for the presence of child plugins before adding them to the mergedPlugins list, but nothing is ever added to assembledPlugins. So if a plugin exists in a parent and a child, it will end up appearing twice in the child's plugin list.

I have re-written this method to fix both these problems. See attached.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Eric Brown - 15/Feb/07 03:12 AM
This bug was inadvertently fixed by jdcasey in r425921 when fixing MNG-1891. Thus, it is fixed in 2.0.5.

The attached patch is no longer relevant as several changes between 2.0.4 and 2.0.5 were merges from trunk and significantly altered the structure of the code.

I code reviewed the 2.0.5 implementation and believe it fixes this problem.

Given the nature of the bug – arbitrary – I don't think there is a reasonable way to write unit or integration tests. Suggest closing this bug as fixed.


John Didion - 16/Feb/07 08:22 AM
Actually, it's pretty easy to unit test this bug. You have a parent POM that defines two or more plugins, and you have a child POM that also defines those plugins, but in a different order. If the ordering in the child POM is respected, the bug is fixed.

Danilo Eiji Seki - 12/Feb/08 02:23 PM
I noticed something strange and made a test. I suspected plugins/reports were being executed in alphabetic order (first by groupId, then by artifactId) and so they are!

For example, I have a problem generating QALab reports in child projects, because QALab plugin was always executed before the reports that generate data. Then I noticed the reports were generated almost in the order I specify them (I use the above alphabetic order, expept for the QALab plugin, that is the last one). Then I imagined that maybe that happens because all my reports are from org. groups while QALab belongs to net..

I tested it by creating a dummy plugin by renaming the groupId of a QALab report plugin to zzz.net.objectlab and deploying it to my local repository. Then I changed my root dependency to this new one and magic, IT WORKS.

I suspect someone is using a sorted collection (tree set, etc). Some display-beautifuly-list is messing things up.