Vincent Siveton wrote:
Yep see for instance MJAVADOC-171
Based on some simple experiments on my machine, the fix for this is simply
to drop @aggregator; it's broken... (at least for reporting plugins that
fork lifecycles like javadoc, jxr and surefire), and its effect can be
easily simulated in normal plugin-level code.
I've posted these remarks in the comments to MJAVADOC-171 and MJAVADOC-137
(which has 13 votes).
build due to the @aggregator stuff.
In MJAVADOC-137, Benjamin proposed to create an AggregatorJavadoc.
IMHO he is on the right way. WDYT?
I like John Allen's strategy, recommended here:
http://jira.codehaus.org/browse/SUREFIRE-348
He suggests a separate mojo (blah:aggregate) that aggregates *data* that
can be run at various levels of the hierarchy. Then the reporting plugins
can/should remain ignorant about aggregation.
This seems like the right choice for test results, but maybe not a good
idea for sources. At any rate, the <aggregate> option does 99% of what's
needed right now AFAIK.
For now, reporting plugins that need forked lifecycles should just drop
@aggregator and simulate its effect with an <aggregate> parameter; then
the first line of your executeReport method should be: "if (aggregate &&
!project.isExecutionRoot()) return;".
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
