My understanding is that this is all related to the work that is being done on the build plan for 2.1.
AFAIK the idea behind @aggregator is that it specifies the mojo as being one that operates on all child modules. So for example javadoc would want to do this in order to provide a unified javadoc of all child modules. A pluging that flags itself as @aggregator needs to know how to operate on all the child modules though, as it should not get invoked for the child modules, only the parent to which it applies. I would have expected that there would be two javadoc mojo's.... something like javadoc:javadoc which just generates the javadoc for the current module, and javadoc:unified-javadoc which would be an @aggregator mojo that produces the unified javadoc of all child modules. Obviously, the javadoc mojo developers did not do this! So what happens next, well the javadoc plugin has some required goals/lifecycle phases that must be executed before it can execute... namely generate-sources... so, Maven being the good boy goes off to all the child modules and does a generate-sources. Once finished, it says OK javadoc, you are ready and starts javadoc in the parent module. OK, so that should be no harm! Enter the site phase, this wants to run reports on each child module, so in each child it does a javadoc:javadoc, so maven says, Oh, I need to ensure generate-sources has run, so it launches a new lifecycle running as far as each generate-resources on each child module. Then site moves onto the next child module and repeats itself! You can see that as different mojo's add the @aggregator jag to existing goals without ensuring that they know how to work in an aggregated mode, problems will arrise. Also if people are binding mojos to the generate-sources phase in their build that are not generating sources but bound there because of missing phases in the lifecycle, they'll be storing up problems for later. The build-plan initiative for 2.1 should solve most of these issues as Maven will be able to figure out the optimum sequence of execution... I say should,because there will be ways that three plugins could still interact to cause a repeat of this issue... though hopefully without such disasterous consequences -Stephen On Feb 5, 2008 11:30 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > Dumb question (possibly): what does the @aggregator annotation do, > exactly? > > I read the doc here: > http://maven.apache.org/developers/mojo-api-specification.html > > It says: "Flags this Mojo to run it in a multi module way, i.e. aggregate > the build with the set of projects listed as modules." > > But I don't understand that. What does it mean to aggregate the build > with its modules? What's a multi-module way? > > Specifically, in 2.4 I added @aggregator to the surefire-report plugin > when I tried to fix SUREFIRE-268 by copying code from the javadoc plugin, > but this appears to have caused SUREFIRE-449: in a 10 project reactor, > project 1's tests are run 10 times; project 2's tests are run 10 times, > project 3's tests are run 10 times, and so on. > > It seems like getting rid of the @aggregator I added in fixes the problem, > but I don't really understand why I added it in the first place, or why > the javadoc plugin has it, or why jxr doesn't. > > How is it supposed to work? > > -Dan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
