You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org> on 2008/08/12 20:45:27 UTC

[jira] Issue Comment Edited: (MJAVADOC-212) AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated

    [ http://jira.codehaus.org/browse/MJAVADOC-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144846#action_144846 ] 

bentmann edited comment on MJAVADOC-212 at 8/12/08 1:44 PM:
---------------------------------------------------------------------

Another idea: Currently, the parameter "aggregate" controls the aggregation behavior of say "javadoc:javadoc". However, this is not reliable, proper aggregation also requires to collectively fork all projects in the reactor. This can only be achieved via the "@aggregator" mojo annotation. So I believe the natural solution is to query the existence of this annotation whereever the code now checks the "aggregate" parameter. Hence, I added a new method {{isAggregator()}} that mojos override to report their aggregating behavior.

The existing parameter "aggregate" is kept only for convenience during the site lifecycle. The implementation of {{canGenerateReport()}} will skip those reports whose aggregator flag doesn't match the value specified by the user via "aggregate". This should allow to run either {{JavadocReport}} or {{AggregateJavadocReport}} without the need for {{<reportSets>}}. The parameter is ignored when the mojos are invoked via cli or build lifecycle, i.e. "mvn javadoc:javadoc -Daggregate=true" will no longer produce aggregated output. Instead, users should call "mvn javadoc:aggregate". That's a break, but I believe that's the only correct way in terms of proper aggregation.

I haven't tested this yet, it's merely a sketch for discussion.

      was (Author: bentmann):
    Another idea: Currently, the parameter "aggregate" controls the aggregation behavior of say "javadoc:javadoc". However, this is not reliable, proper aggregation also requires to collectively fork all projects in the reactor. This can only be achieved via the "@aggregator" mojo annotation. So I believe the natural solution is to query the existence of this annotation whereever the code now checks the "aggregate" parameter. Hence, I added a new method {{isAggregator()}} that mojos override to report their aggregating behavior.

The existing parameter "aggregate" is kept only for convenience during the site lifecycle. The implementation of {{canGenerateReport()}} will skip those reports whose aggregator flag doesn't match the value specified by the user via "aggregate". This should allow to run either {{JavadocReport}} or {{AggregateJavadocReport}} without the need for {{<reportSets>}}.

I haven't tested this yet, it's merely a sketch for discussion.
  
> AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: MJAVADOC-212
>                 URL: http://jira.codehaus.org/browse/MJAVADOC-212
>             Project: Maven 2.x Javadoc Plugin
>          Issue Type: Bug
>    Affects Versions: 2.5
>            Reporter: Vincent Siveton
>            Priority: Critical
>             Fix For: 2.5
>
>         Attachments: javadoc-aggregation.patch, MJAVADOC-212.patch
>
>
> In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are used by default. Due to the following in the code,
> {code:title=AbstractJavadocMojo.java|borderStyle=solid}
>         if ( aggregate && !project.isExecutionRoot() )
>         {
>             return;
>         }
> {code} 
> the report is skipped.

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