Maven Javadoc Plugin
  1. Maven Javadoc Plugin
  2. MJAVADOC-212

AggregatorJavadocReport/AggregatorTestJavadocReport are used by default in aggregator and no reports are generated

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5
    • Labels:
      None

      Description

      In multimodule way, AggregatorJavadocReport/AggregatorTestJavadocReport are used by default. Due to the following in the code,

      AbstractJavadocMojo.java
              if ( aggregate && !project.isExecutionRoot() )
              {
                  return;
              }
      

      the report is skipped.

      1. javadoc-aggregation.patch
        6 kB
        Benjamin Bentmann
      2. MJAVADOC-212.patch
        2 kB
        Siveton Vincent

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          1d 10h 59m 1 Siveton Vincent 13/Aug/08 18:02
          Mark Thomas made changes -
          Workflow jira [ 12959961 ] Default workflow, editable Closed status [ 12996884 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 00:11:46 UTC 2015 [ 1428279106587 ]
          Mark Thomas made changes -
          Workflow jira [ 12722450 ] Default workflow, editable Closed status [ 12762432 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 11:56:47 UTC 2015 [ 1428235007093 ]
          Siveton Vincent made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Vincent Siveton [ siveton ]
          Resolution Fixed [ 1 ]
          Hide
          Siveton Vincent added a comment -

          Patch applied in r685691 and r685692, snapshot deployed.
          Thanks!

          Show
          Siveton Vincent added a comment - Patch applied in r685691 and r685692 , snapshot deployed. Thanks!
          Hide
          Benjamin Bentmann added a comment -

          Considering the penalty of the forked lifecycles during the site generation of every module caused by "@aggregator" on the new mojos, I would however assume that people will sooner than later user <reportSets> to disable them from running in child modules.

          Show
          Benjamin Bentmann added a comment - Considering the penalty of the forked lifecycles during the site generation of every module caused by "@aggregator" on the new mojos, I would however assume that people will sooner than later user <reportSets> to disable them from running in child modules.
          Benjamin Bentmann made changes -
          Attachment javadoc-aggregation.patch [ 36468 ]
          Hide
          Benjamin Bentmann added a comment - - edited

          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.

          Show
          Benjamin Bentmann added a comment - - edited 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.
          Siveton Vincent made changes -
          Attachment MJAVADOC-212.patch [ 36465 ]
          Hide
          Siveton Vincent added a comment -

          Proposed patch.
          By default, AggregatorJavadocReport/AggregatorTestJavadocReport will never be called at least aggregator parameter is specified.

          Show
          Siveton Vincent added a comment - Proposed patch. By default, AggregatorJavadocReport/AggregatorTestJavadocReport will never be called at least aggregator parameter is specified.
          Hide
          Siveton Vincent added a comment -

          A solution could be to move the aggregate parameter into AggregatorJavadocReport/AggregatorTestJavadocReport or to create a new parameter, like aggregator, only for these mojos.

          Show
          Siveton Vincent added a comment - A solution could be to move the aggregate parameter into AggregatorJavadocReport/AggregatorTestJavadocReport or to create a new parameter, like aggregator, only for these mojos.
          Hide
          Siveton Vincent added a comment -

          In fact, I noticed some warn like the following:

          [INFO] Skipped "JavaDocs" report, file "apidocs/index.html" already exists for the English version.
          

          So, AggregatorJavadocReport and JavadocReport are both used. It is normal IMHO since the PluginManager invokes all MavenReport.

          Show
          Siveton Vincent added a comment - In fact, I noticed some warn like the following: [INFO] Skipped "JavaDocs" report, file "apidocs/index.html" already exists for the English version. So, AggregatorJavadocReport and JavadocReport are both used. It is normal IMHO since the PluginManager invokes all MavenReport.
          Hide
          Siveton Vincent added a comment -

          To reproduce it, go to plugin-tools or plugin-testing and run:

          plugin-tools>mvn clean site:stage -DstagingDirectory=C:\target -X -Ddebug -Preporting 
          

          You will see an empty maven-plugin-tools-api\apidocs\index.html or maven-plugin-tools-api\testapidocs\index.html

          Show
          Siveton Vincent added a comment - To reproduce it, go to plugin-tools or plugin-testing and run: plugin-tools>mvn clean site:stage -DstagingDirectory=C:\target -X -Ddebug -Preporting You will see an empty maven-plugin-tools-api\apidocs\index.html or maven-plugin-tools-api\testapidocs\index.html
          Siveton Vincent made changes -
          Link This issue is related to MJAVADOC-196 [ MJAVADOC-196 ]
          Siveton Vincent made changes -
          Field Original Value New Value
          Fix Version/s 2.5 [ 14120 ]
          Siveton Vincent created issue -

            People

            • Assignee:
              Siveton Vincent
              Reporter:
              Siveton Vincent
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development