Possible problem with @aggregator and forked lifecycles

In order to understand how the clover report works, here's a diagram: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/site/resources/images/clover-report-architecture.jpg

Please note that this diagram was done before I modified the clover report mojo to be an aggregator.

Could this be due to MNG-2054? Have you tried the new 2.0.3 release?

Hi Mike,

I was using 2.0.3-SNAPSHOT. Just tried with 2.0.3 final and I'm getting the same result...

Thanks

Moving to blocker as the clover plugin cannot be released before this is fixed

This only happens as part of the site, because it doesn't support using @aggregator for reports. I think this is a dupe - I'll search.

This is a feature request, so can't be done for 2.0.4. I'd suggest, for this release, that you split into clover:clover and clover:report, with the first being @aggregator and not implementing MavenReport, and the latter not aggregating and implementing MavenReport.

ok, I think I was mistaken. I was proabbly thinking of when reports couldn't fork lifecycles. So this indeed seems to be a bug, but a very risky one to change in the short term. Can yo use the above workaround?

The other thing you can do is to have an isAggregating flag in the clover plugin, and set that in the forked lifecycle.

I think it may be simpler to try looking at this in the context of any new lifecycle features we might plan for 2.1. Aggregation is a bit of a problem across the board right now, with clover being one of the more extreme use cases.

See revId: 619720 on trunk...does this do enough to prevent bound-aggregator weirdness?

619720 improves the logic of skipping vs. warning of deprecation (deprecated to bind aggregator mojos to the lifecycle now), to prevent printing a warning message when the mojo will be skipped.

thinking about this more, if an aggregator mojo is bound simultaneously to two module poms in the same reactor, where should it execute? If it's bound to a pom at all, then merely the root location of the reactor may change whether the aggregator runs or not, using the logic from revId: 619721.

I'm commenting that code out until I can think about this more, and come up with something. I really think the safest solution may be to prohibit aggregators in the lifecycle at all.

We need to support aggregators in the lifecycle, i'm convinced of that, but they should only run at the root of the execution, just like its done from the cli.

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

The ounce:application goal is an aggregator that is intended to be bound to a pom. We need to collect the information about all child projects. I think that where ever in the tree an aggregator is defined, it should run once there. Meaning if it shows up in two children, well then it runs for each of those (once for each of those trees)

The aggregation part isn't really what is needed if there is another way to get the fully interpolated child projects....this is what is really needed.