Details

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

      Description

      In version 2.2, javadoc aggregation was configurable using the configuration property "aggregate". In version 2.3, all javadoc goals got the @aggregator attribute added to its mojos (through a change in org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now always run aggregated regardless of the configuration setting. This breaks our build as we require non-aggregated javadoc execution in our multi-module poms. Please fix this so this is once again configurable and backwards compatible with previous versions of the javadoc plug-in.

        Issue Links

          Activity

          Hide
          skaze added a comment -

          If you run the javadoc plugin as report then the @aggregator is ignored (see MNG-2184), I have removed the @aggregator from my local version of the plugin and it passes all its tests but i expect the JavadocJarMojo might suffer (haven't tested yet and i would have too look at the code some more). Personally I cant see why one would want any of the javadoc mojo's functionality to run as an aggregator. Note the 'aggregate' report mojo option is actually implemented inside the mojo, ie. the report exits if it's already been run in the reactor and aggregate is true.

          Show
          skaze added a comment - If you run the javadoc plugin as report then the @aggregator is ignored (see MNG-2184 ), I have removed the @aggregator from my local version of the plugin and it passes all its tests but i expect the JavadocJarMojo might suffer (haven't tested yet and i would have too look at the code some more). Personally I cant see why one would want any of the javadoc mojo's functionality to run as an aggregator. Note the 'aggregate' report mojo option is actually implemented inside the mojo, ie. the report exits if it's already been run in the reactor and aggregate is true.
          Hide
          Peter Hendriks added a comment -

          We run the goals "clean javadoc:javadoc install", i.e. we explicitly call the javadoc goal. In the past when running this on a multi-module pom, this triggered the javadoc:javadoc goal on each module. With version 2.3, this triggers the [javadoc:javadoc] as (aggregator-style) on the main pom, and no separate javadoc is generated anymore.

          I looked up the bug you linked to but I find it difficult to relate this to this problem. I tried looking up some documentation about @aggregator, but it is not described in the Mojo documentation. I agree with you that the @aggregator seems at odds with the "aggregate" property, but it may be my lack of understanding this feature.

          Do you know where I can find more information about how aggregator is supposed to work, and if there are work-arounds to disable aggregator-style?

          Show
          Peter Hendriks added a comment - We run the goals "clean javadoc:javadoc install", i.e. we explicitly call the javadoc goal. In the past when running this on a multi-module pom, this triggered the javadoc:javadoc goal on each module. With version 2.3, this triggers the [javadoc:javadoc] as (aggregator-style) on the main pom, and no separate javadoc is generated anymore. I looked up the bug you linked to but I find it difficult to relate this to this problem. I tried looking up some documentation about @aggregator, but it is not described in the Mojo documentation. I agree with you that the @aggregator seems at odds with the "aggregate" property, but it may be my lack of understanding this feature. Do you know where I can find more information about how aggregator is supposed to work, and if there are work-arounds to disable aggregator-style?
          Hide
          skaze added a comment -

          My observation should have been that when report MOJOs are run from the site plugin they do not honour @aggregator declaration, this is what brett is confirming here. Running the MOJO external to site (i.e. via the command line javadoc:javadoc) appears, according to your experiences, to allow the MOJO to run as an aggregator. I would raise this issue on the @dev list and ask why has this MOJO been made an @aggregator, seems like a mistake to me too. As a workaround either drop back a version or build your own patched version of the plugin?

          Show
          skaze added a comment - My observation should have been that when report MOJOs are run from the site plugin they do not honour @aggregator declaration, this is what brett is confirming here . Running the MOJO external to site (i.e. via the command line javadoc:javadoc) appears, according to your experiences, to allow the MOJO to run as an aggregator. I would raise this issue on the @dev list and ask why has this MOJO been made an @aggregator, seems like a mistake to me too. As a workaround either drop back a version or build your own patched version of the plugin?
          Hide
          Francois Fernandes added a comment -

          Got a problem with the aggregator here. Since javadoc 2.3 and the plugin running as an aggregator, our build is broken. Due to the forking of a lifecycle there are arifacts not beeing generated and referenced by other modules. This results in a build failure. Up until now I was unable to create a simple testcase which reproduces our problem. But here is the basic layout of our project.

          parent
           +-- assembly
           +-- submodule-A
               +-- mod-A
               +-- mod-B
               +-- mod-C
          

          In our case the mod-B produces a javadoc jar (using javadoc:jar) und creates a assembly using the assembly (attached mojo) plugin. Both mojos are beeing executed at the package phase. The assembly module has a dependecy to the mod-B generated assembly as a zip file. If the javadoc mojo executes and forks the lifecycle, the assembly hasn't been created yet. That means that building assembly is failing due to the missing depenency of mod-B:zip.

          Show
          Francois Fernandes added a comment - Got a problem with the aggregator here. Since javadoc 2.3 and the plugin running as an aggregator, our build is broken. Due to the forking of a lifecycle there are arifacts not beeing generated and referenced by other modules. This results in a build failure. Up until now I was unable to create a simple testcase which reproduces our problem. But here is the basic layout of our project. parent +-- assembly +-- submodule-A +-- mod-A +-- mod-B +-- mod-C In our case the mod-B produces a javadoc jar (using javadoc:jar) und creates a assembly using the assembly (attached mojo) plugin. Both mojos are beeing executed at the package phase. The assembly module has a dependecy to the mod-B generated assembly as a zip file. If the javadoc mojo executes and forks the lifecycle, the assembly hasn't been created yet. That means that building assembly is failing due to the missing depenency of mod-B:zip.
          Hide
          Siveton Vincent added a comment -

          Issue which added @aggregator feature

          Show
          Siveton Vincent added a comment - Issue which added @aggregator feature
          Hide
          Benjamin Bentmann added a comment -

          I must confess I still could not figure out how exactly @aggregator affects the plugin's execution, the Mojo API is quite short about this. If there are use-cases that require this annotation, then it might be worth to consider splitting mojos into two: one that has @aggregator and one that has not. This way, the user can choose the appropriate mojo. The Assembly Plugin uses this approach, too.

          Show
          Benjamin Bentmann added a comment - I must confess I still could not figure out how exactly @aggregator affects the plugin's execution, the Mojo API is quite short about this. If there are use-cases that require this annotation, then it might be worth to consider splitting mojos into two: one that has @aggregator and one that has not. This way, the user can choose the appropriate mojo. The Assembly Plugin uses this approach, too.
          Hide
          Dan Fabulich added a comment -

          I'm pretty sure MNG-2184 is to blame here; it seems clear that reporting plugins that use forked lifecycles should not use @aggregator. At least in this case, it seems to be harmful and unnecessary.

          FYI, I can't get maven-javadoc-plugin to "mvn install" from trunk (I get test failures), but the 2.3 tag builds just fine; when I remove the @aggregator tag from the mojo, it seems to work perfectly.

          http://www.nabble.com/%40aggregator-mojo-annotation-td15302246s177.html

          Show
          Dan Fabulich added a comment - I'm pretty sure MNG-2184 is to blame here; it seems clear that reporting plugins that use forked lifecycles should not use @aggregator. At least in this case, it seems to be harmful and unnecessary. FYI, I can't get maven-javadoc-plugin to "mvn install" from trunk (I get test failures), but the 2.3 tag builds just fine; when I remove the @aggregator tag from the mojo, it seems to work perfectly. http://www.nabble.com/%40aggregator-mojo-annotation-td15302246s177.html
          Hide
          Wendy Smoak added a comment -

          I added an integration test for this in r632888. Unfortunately, I can't figure out how to get it to fail when javadoc plugin's 'jar' goal is run from the pom.

          http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-137/

          If you check that out and execute 'mvn javadoc:jar' you do not get the javadoc jars. It says:

          INFO] [javadoc:jar]
          [INFO] Not executing Javadoc as the project is not a Java classpath-capable package

          Change pluginManagement to version 2.2 and it will work.

          Any idea how to demonstrate that from a pom? I really don't want to touch the code without a failing automated test.

          Show
          Wendy Smoak added a comment - I added an integration test for this in r632888. Unfortunately, I can't figure out how to get it to fail when javadoc plugin's 'jar' goal is run from the pom. http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-137/ If you check that out and execute 'mvn javadoc:jar' you do not get the javadoc jars. It says: INFO] [javadoc:jar] [INFO] Not executing Javadoc as the project is not a Java classpath-capable package Change pluginManagement to version 2.2 and it will work. Any idea how to demonstrate that from a pom? I really don't want to touch the code without a failing automated test.
          Hide
          Wendy Smoak added a comment -

          Okay, now in r632911 we have a properly failing test using the invoker plugin. Next step is to revert the changes from MJAVADOC-104.

          Show
          Wendy Smoak added a comment - Okay, now in r632911 we have a properly failing test using the invoker plugin. Next step is to revert the changes from MJAVADOC-104 .
          Hide
          Wendy Smoak added a comment -

          The changes from MJAVADOC-104 (less some noise) have been reverted [1] and a new snapshot deployed. I'll close this in a few days if there are no further comments.

          [1] http://svn.apache.org/viewvc?rev=632945&view=rev

          Show
          Wendy Smoak added a comment - The changes from MJAVADOC-104 (less some noise) have been reverted [1] and a new snapshot deployed. I'll close this in a few days if there are no further comments. [1] http://svn.apache.org/viewvc?rev=632945&view=rev

            People

            • Assignee:
              Unassigned
              Reporter:
              Peter Hendriks
            • Votes:
              14 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development