[
http://jira.codehaus.org/browse/MNG-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123017
]
John Casey commented on MNG-2184:
---------------------------------
But what are the implications for that? If they're bound to the usual root pom
of a project hierarchy, then they will always be included in the build process,
because all modules should inherit from that top-level pom, and maven will get
the opportunity to limit the mojo to one execution. However, if the aggregator
is bound to one of the child modules, then it would run when the child is built
in isolation (since it would be included in the build-plan of the root
project), but NOT when the build is run from the top-level POM (which would be
the root project, and the aggregator isn't bound to this POM but one of its
modules.
So, that leaves us with some sort of session attribute that tracks the
execution of aggregators, to limit their execution to once-per-build.
Now, what if two of the child modules specify a binding to the same aggregator
mojo, with different configurations? In this case, it will all fall apart,
since the binding project is not the root project, and both aggregator bindings
really are meant to execute.
What do we do in those cases??
Why do we absolutely need aggregator mojos that are bound to the lifecycle?
What are the real use cases, and is there a better solution that we could
design? Personally, I'd much rather see the pre- and post-execution mojo thing
that we talked about in the comments of:
http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
IF we could find a way to make their binding and execution behavior consistent
regardless of how a collection of POMs is built (i.e. which ones are included
should not modify the build of any one of them).
> Possible problem with @aggregator and forked lifecycles
> -------------------------------------------------------
>
> Key: MNG-2184
> URL: http://jira.codehaus.org/browse/MNG-2184
> Project: Maven 2
> Issue Type: Bug
> Components: Design, Patterns & Best Practices, Plugins and Lifecycle
> Affects Versions: 2.0.3
> Environment: Revision 974 of Cargo
> (https://svn.codehaus.org/cargo/cargo/trunk/core/api/)
> Reporter: Vincent Massol
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.1
>
> Attachments: cargo.log
>
>
> In the Clover plugin the report mojo is an aggregator
> (http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java).
> It also spawns a forked lifecycle:
> {code}
> * @execute phase="test" lifecycle="clover"
> * @aggregator
> {code}
> When I run this clover report on the Cargo API module, which contains
> children modules, all the modules are executed several times as shown in the
> attached logs. They should be executed only once. The @aggregator is supposed
> to execute only once and it executes several times.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
