Maven 1

maven 1.1 fails to run commons-attributes in mutliproject mode on a war project

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: 1.1-beta-2
  • Fix Version/s: 1.1-beta-3
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

Attached zip contains a minimalist multiproject using commons-attributes that demonstrates the bug.

  • head (top level project)
  • jar (minimalist jar project) : Sample.java has a "java.util.Date" attribute
  • war (minimalist war project) : Sample.java has a "java.util.Date" attribute

When runing "maven war:install" on war project, attributes are generated as expected.

When running from "head" project using "maven multiproject:install", commons-attributes are

  • generated as expected for the jar
  • NOT generated in the war (no log from plugin)

I don't know if this is a maven, multiproject-plugin, war-plugin or commons-attributes-plugin bug.

Please notice commons-attributes plugin uses a preGoal to automatically register itself.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
nicolas de loof added a comment -

I've made some other tests: I've converter the war project in the attached zip to a simple jar.

commons-attributes plugin is executed ONLY on the FIRST project that uses it in the multiproject build.
-> this bug is not related to war plugin.

I've patched my commons-attribute plugin Jelly script to echo on <preGoal name="java:compile"> , before anything from plugin is executed.
The pregoal is NOT executed after first subproject is build by multiproject.
-> this bug is not related to commons-attributes plugin

Now, there is AFAIK only one possible source for this bug :
The reactor does not handle preGoals registration from plugins as expected (as it does on maven 1.0.x)

I don't know about maven Internals and cannot go deeper on this issue.

Show
nicolas de loof added a comment - I've made some other tests: I've converter the war project in the attached zip to a simple jar. commons-attributes plugin is executed ONLY on the FIRST project that uses it in the multiproject build. -> this bug is not related to war plugin. I've patched my commons-attribute plugin Jelly script to echo on <preGoal name="java:compile"> , before anything from plugin is executed. The pregoal is NOT executed after first subproject is build by multiproject. -> this bug is not related to commons-attributes plugin Now, there is AFAIK only one possible source for this bug : The reactor does not handle preGoals registration from plugins as expected (as it does on maven 1.0.x) I don't know about maven Internals and cannot go deeper on this issue.
Hide
Permalink
Lukas Theussl added a comment -

I think (I am not sure, I have to check the archives) that this is actually the intented behavior in maven 1.1. A pregoal is always only executed once in a build cycle, as you usually don't want the same pregoal executed several times from different goals to avoid overhead. If you want to make sure that a goal gets executed, you have to use the <attainGoal> tag. At least that's the behavior that I would expect.

Show
Lukas Theussl added a comment - I think (I am not sure, I have to check the archives) that this is actually the intented behavior in maven 1.1. A pregoal is always only executed once in a build cycle, as you usually don't want the same pregoal executed several times from different goals to avoid overhead. If you want to make sure that a goal gets executed, you have to use the <attainGoal> tag. At least that's the behavior that I would expect.
Hide
Permalink
nicolas de loof added a comment -

I can agree with this 1.1 new requirement for only-1-run preGoals.

This may then require some upgrade to commons-attributes and html2xdoc plugins :
html2xodc uses a xdoc:init preGoal to run if maven.html2xdoc.enabled=true
(I don't know other official plugins that use pre/post Goals)

So this bug can be moved from MAVEN to MPHTMLXDOC

Show
nicolas de loof added a comment - I can agree with this 1.1 new requirement for only-1-run preGoals. This may then require some upgrade to commons-attributes and html2xdoc plugins : html2xodc uses a xdoc:init preGoal to run if maven.html2xdoc.enabled=true (I don't know other official plugins that use pre/post Goals) So this bug can be moved from MAVEN to MPHTMLXDOC
Hide
Permalink
Lukas Theussl added a comment -

There was actually an issue open for that: MPHTMLXDOC-6, which I closed as won't fix, but I am not so sure on that anymore.

I'll leave this one open for the moment as I think there is a legitimate bug somewhere buried here: prereqs seem to be called once only as long as you don't call attainGoal somewhere in between - I'll try to construct a simple test case.

Just for reference: see also my struggles at MPXDOC-181.

Show
Lukas Theussl added a comment - There was actually an issue open for that: MPHTMLXDOC-6, which I closed as won't fix, but I am not so sure on that anymore. I'll leave this one open for the moment as I think there is a legitimate bug somewhere buried here: prereqs seem to be called once only as long as you don't call attainGoal somewhere in between - I'll try to construct a simple test case. Just for reference: see also my struggles at MPXDOC-181.
Hide
Permalink
Lukas Theussl added a comment -

Same as MAVEN-1638.

Show
Lukas Theussl added a comment - Same as MAVEN-1638.
Hide
Permalink
Lukas Theussl added a comment -

This is not the same as MAVEN-1638. However, I am a bit confused by the attached test case, running war:install in the war project does not generate the attributes, just like in the multiproject case. Maybe something has changed, can someone confirm that with the latest versions of the plugins?

Show
Lukas Theussl added a comment - This is not the same as MAVEN-1638. However, I am a bit confused by the attached test case, running war:install in the war project does not generate the attributes, just like in the multiproject case. Maybe something has changed, can someone confirm that with the latest versions of the plugins?

People

Vote (0)
Watch (2)

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.