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

Impossible to aggregate javadoc if snapshot never built

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      6

      Description

      In a multi-module projet, I build an aggregated Javadoc for the site.

      The project is built with "mvn clean deploy site-deploy"

      When I add a new project, the next build always fails because the javadoc plugin can't find at least one snapshot for the new added module

      In the following example, I added a new module tele.persistance:pers-commons, which have never been built before.
      Maven tries to download it but it can't find it (never build before).

       [INFO] [site:site]
      [WARNING] Unable to load parent project from repository: Could not find the model file '/continuum-folders/working-directory/116/../pom.xml'.
      [INFO] Skipped "About" report, file "index.html" already exists for the English version.
      [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
      [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
      [INFO] Generate "JavaDocs" report.
      [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates from mirror.snapshots
      [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking for updates from mirror.snapshots
      [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking for updates from mirror.snapshots
      [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT: checking for updates from mirror.snapshots
      Downloading: http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
      [WARNING] Unable to get resource 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository mirror.snapshots (http://proxy/maven2-snapshots/repository)
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Failed to resolve artifact.
      
      Missing:
      ----------
      1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
      
        Try downloading the file manually from the project website.
      
        Then, install it using the command: 
            mvn install:install-file -DgroupId=tele.persistance -DartifactId=pers-commons \
                -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
      
        Path to dependency: 
        	1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
        	2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
      
      ----------
      1 required artifact is missing.
      
      for artifact: 
        tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
      
      from the specified remote repositories:
        central (http://repo1.maven.org/maven2),
        mirror.snapshots (http://proxy/maven2-snapshots/repository)
      

      If I make an intermediate "install", everything works fine

      1. log.txt
        404 kB
        Damien Lecan
      2. tiles-log.txt
        15 kB
        Antonio Petrelli

        Issue Links

          Activity

          Hide
          Antonio Petrelli added a comment -

          The same problem appears during the use of the release plugin: the release fails and I have to install the checked-out code locally before retrying the release.

          Show
          Antonio Petrelli added a comment - The same problem appears during the use of the release plugin: the release fails and I have to install the checked-out code locally before retrying the release.
          Hide
          Arne Degenring added a comment -

          I face the same problem. It seems to be a regression, as the problem does not occur with maven-javadoc-plugin 2.0.

          Show
          Arne Degenring added a comment - I face the same problem. It seems to be a regression, as the problem does not occur with maven-javadoc-plugin 2.0.
          Arne Degenring made changes -
          Field Original Value New Value
          Link This issue is related to MJAVADOC-111 [ MJAVADOC-111 ]
          Paul Gier made changes -
          Link This issue depends upon MJAVADOC-119 [ MJAVADOC-119 ]
          Paul Gier made changes -
          Link This issue relates to MJAVADOC-119 [ MJAVADOC-119 ]
          Vincent Siveton made changes -
          Link This issue depends upon MJAVADOC-119 [ MJAVADOC-119 ]
          Hide
          Damien Lecan added a comment -

          Same thing with releases version of artifacts.

          This is a major issue in a multi-module project when you want to release the project and the aggregated javadoc.

          As the maven-release-plugin does "deploy site-deploy" when release:perform, this step always fails because of this bug.

          Show
          Damien Lecan added a comment - Same thing with releases version of artifacts. This is a major issue in a multi-module project when you want to release the project and the aggregated javadoc. As the maven-release-plugin does "deploy site-deploy" when release:perform, this step always fails because of this bug.
          Hide
          Antonio Petrelli added a comment -

          Attached a small test case.
          I noticed that the bug is triggered if a module depends on another, even if in correct order.
          This bug is still present in the 2.3 version of the plugin.

          Show
          Antonio Petrelli added a comment - Attached a small test case. I noticed that the bug is triggered if a module depends on another, even if in correct order. This bug is still present in the 2.3 version of the plugin.
          Antonio Petrelli made changes -
          Attachment javadoc-plugin-test-case.zip [ 28575 ]
          Hide
          Antonio Petrelli added a comment -

          Could someone add the "Testcase included" flag?
          Thanks.

          Show
          Antonio Petrelli added a comment - Could someone add the "Testcase included" flag? Thanks.
          Hide
          Olivier Lamy added a comment -

          testcase included flag to yes.

          Show
          Olivier Lamy added a comment - testcase included flag to yes.
          Olivier Lamy made changes -
          Testcase included yes
          Vincent Siveton made changes -
          Fix Version/s 2.4 [ 13630 ]
          Hide
          Vincent Siveton added a comment -

          Fixed in r617996.
          Snapshot deployed but you need to have maven 2.0.8 to run it.

          Show
          Vincent Siveton added a comment - Fixed in r617996. Snapshot deployed but you need to have maven 2.0.8 to run it.
          Vincent Siveton made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          Assignee Vincent Siveton [ siveton ]
          Hide
          Damien Lecan added a comment -

          I tried with Maven 2.0.8 and maven-javadoc-plugin-2.4-20080203.152011-3

          [INFO] Generate "JavaDocs" report.
          [INFO] snapshot tele.persistance:pers-commons:jar:1.3.0-M1-SNAPSHOT: checking for updates from apache.snapshots
          Downloading: http://people.apache.org/maven-snapshot-repository/tele/persistance/pers-commons/1.3.0-M1-SNAPSHOT/pers-commons-1.3.0-M1-SNAPSHOT.jar
          [WARNING] The dependency: [tele.persistance:pers-commons:jar:1.3.0-M1-SNAPSHOT} can't be resolved but has been found in the reactor (probably snapshots).
          This dependency has been excluded from the Javadoc classpath. You should rerun javadoc after executing mvn install.
          [WARNING] IGNORED to add some artifacts in the classpath. See above.
          
          ...
          
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Error during page generation
          
          Embedded error: Error rendering Maven report: Missing:
          ----------
          1) tele.persistance:pers-test:jar:tests:1.3.0-M1-SNAPSHOT
          
            Try downloading the file manually from the project website.
          
            Then, install it using the command: 
                mvn install:install-file -DgroupId=tele.persistance -DartifactId=pers-test -Dversion=1.3.0-M1-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file
          
          ...
          

          I don't know if javadoc is correctly generated when I see all those WARNING messages.
          Then build fails because of a dependency with "tests" classifier.

          2 questions :

          • when a jar file located in reactor is excluded from javadoc, are corresponding project's classes still included in javadoc ? (aggregate = true)
          • are classifiers handled by reactor jar exclusion ?
          Show
          Damien Lecan added a comment - I tried with Maven 2.0.8 and maven-javadoc-plugin-2.4-20080203.152011-3 [INFO] Generate "JavaDocs" report. [INFO] snapshot tele.persistance:pers-commons:jar:1.3.0-M1-SNAPSHOT: checking for updates from apache.snapshots Downloading: http: //people.apache.org/maven-snapshot-repository/tele/persistance/pers-commons/1.3.0-M1-SNAPSHOT/pers-commons-1.3.0-M1-SNAPSHOT.jar [WARNING] The dependency: [tele.persistance:pers-commons:jar:1.3.0-M1-SNAPSHOT} can't be resolved but has been found in the reactor (probably snapshots). This dependency has been excluded from the Javadoc classpath. You should rerun javadoc after executing mvn install. [WARNING] IGNORED to add some artifacts in the classpath. See above. ... [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error during page generation Embedded error: Error rendering Maven report: Missing: ---------- 1) tele.persistance:pers-test:jar:tests:1.3.0-M1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=tele.persistance -DartifactId=pers-test -Dversion=1.3.0-M1-SNAPSHOT -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file ... I don't know if javadoc is correctly generated when I see all those WARNING messages. Then build fails because of a dependency with "tests" classifier. 2 questions : when a jar file located in reactor is excluded from javadoc, are corresponding project's classes still included in javadoc ? (aggregate = true) are classifiers handled by reactor jar exclusion ?
          Hide
          Vincent Siveton added a comment -

          Reopen since checkMissingArtifactsInReactor() doesnt take care of classifier.

          Show
          Vincent Siveton added a comment - Reopen since checkMissingArtifactsInReactor() doesnt take care of classifier.
          Vincent Siveton made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Vincent Siveton added a comment -

          Damien, did you call mvn site or mvn javadoc:javadoc?
          Could you send us a log with -X?

          Show
          Vincent Siveton added a comment - Damien, did you call mvn site or mvn javadoc:javadoc? Could you send us a log with -X?
          Hide
          Damien Lecan added a comment -

          > did you call mvn site or mvn javadoc:javadoc?

          mvn -DreleaseProfile=true clean deploy site-deploy

          So both site and javadoc:javadoc together.

          Log file is coming...

          Show
          Damien Lecan added a comment - > did you call mvn site or mvn javadoc:javadoc? mvn -DreleaseProfile=true clean deploy site-deploy So both site and javadoc:javadoc together. Log file is coming...
          Hide
          Damien Lecan added a comment -

          Log file for mvn -X -DreleaseProfile=true clean deploy site-deploy in attachement.

          Good luck

          Show
          Damien Lecan added a comment - Log file for mvn -X -DreleaseProfile=true clean deploy site-deploy in attachement. Good luck
          Damien Lecan made changes -
          Attachment log.txt [ 32404 ]
          Hide
          Damien Lecan added a comment -

          Vincent, do you need more information to fix the problem ?

          Show
          Damien Lecan added a comment - Vincent, do you need more information to fix the problem ?
          Hide
          Wendy Smoak added a comment -

          "mvn -DreleaseProfile=true clean deploy site-deploy" works for me with the latest maven-javadoc-plugin snapshot and the attached example.

          (Well, after adding <distributionManagement> – for future examples, you can use something like file:///tmp/repo-MJAVADOC-116 as the deployment repo url, and likewise for the site deployment url.)

          I'm not sure of the timing, but this may have been fixed by along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator.

          Show
          Wendy Smoak added a comment - "mvn -DreleaseProfile=true clean deploy site-deploy" works for me with the latest maven-javadoc-plugin snapshot and the attached example. (Well, after adding <distributionManagement> – for future examples, you can use something like file:///tmp/repo-MJAVADOC-116 as the deployment repo url, and likewise for the site deployment url.) I'm not sure of the timing, but this may have been fixed by along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator.
          Hide
          Damien Lecan added a comment -

          Still doesn't work with classifiers

          Show
          Damien Lecan added a comment - Still doesn't work with classifiers
          Hide
          Vincent Siveton added a comment -

          Damien, it seems that it is due to @requiresDependencyResolution, not the Javadoc plugin.
          Could you confirm that the error comes from DefaultPluginManager ?

          Show
          Vincent Siveton added a comment - Damien, it seems that it is due to @requiresDependencyResolution, not the Javadoc plugin. Could you confirm that the error comes from DefaultPluginManager ?
          Hide
          Wendy Smoak added a comment -

          As mentioned, I can't reproduce this with the attached example.

          I'd like to stage the 2.4 release on Friday.

          In order for this to be included, I need a sample project and steps to reproduce the problem. Otherwise it will either be bumped to 2.5 or closed as Cannot Reproduce. Thanks!

          Show
          Wendy Smoak added a comment - As mentioned, I can't reproduce this with the attached example. I'd like to stage the 2.4 release on Friday. In order for this to be included, I need a sample project and steps to reproduce the problem. Otherwise it will either be bumped to 2.5 or closed as Cannot Reproduce. Thanks!
          Hide
          Antonio Petrelli added a comment -

          Wendy, can you wait one day? I tried some days ago with Tiles and it didn't work.

          Show
          Antonio Petrelli added a comment - Wendy, can you wait one day? I tried some days ago with Tiles and it didn't work.
          Hide
          Damien Lecan added a comment -

          Here is a test case which reproduces problem with classifiers and aggregated javadoc.

          It is based on previous patch with following updates :

          • javadoc version 2.4-SNAPSHOT
          • build module 1 test jar ("test-jar" classifier)
          • module 2 depends on module 1 jar AND test-jar. They have to be declared together.

          Try "mvn -DreleaseProfile=true clean deploy site-deploy", it will fail (maven 2.0.8)

          Things to notice :

          • with aggregate = false, it works
          • in module 2, with exactly one of the 2 dependencies (jar OR test-jar), it works (??)

          Is it enough to reproduce bug ?

          Show
          Damien Lecan added a comment - Here is a test case which reproduces problem with classifiers and aggregated javadoc. It is based on previous patch with following updates : javadoc version 2.4-SNAPSHOT build module 1 test jar ("test-jar" classifier) module 2 depends on module 1 jar AND test-jar. They have to be declared together. Try "mvn -DreleaseProfile=true clean deploy site-deploy", it will fail (maven 2.0.8) Things to notice : with aggregate = false, it works in module 2, with exactly one of the 2 dependencies (jar OR test-jar), it works (??) Is it enough to reproduce bug ?
          Damien Lecan made changes -
          Hide
          Damien Lecan added a comment -

          Same test cas as before, but without any target folders.

          Show
          Damien Lecan added a comment - Same test cas as before, but without any target folders.
          Damien Lecan made changes -
          Hide
          Antonio Petrelli added a comment -

          Creating Javadocs with:
          mvn javadoc:javadoc
          does not work with Tiles:
          http://svn.apache.org/repos/asf/tiles/framework/trunk/

          Added tiles-log.txt as attachment.

          Show
          Antonio Petrelli added a comment - Creating Javadocs with: mvn javadoc:javadoc does not work with Tiles: http://svn.apache.org/repos/asf/tiles/framework/trunk/ Added tiles-log.txt as attachment.
          Antonio Petrelli made changes -
          Attachment tiles-log.txt [ 33029 ]
          Hide
          Damien Lecan added a comment -

          Antonio, same problem as me with classifiers.

          Show
          Damien Lecan added a comment - Antonio, same problem as me with classifiers.
          Wendy Smoak made changes -
          Fix Version/s 2.4 [ 13630 ]
          Hide
          Damien Lecan added a comment -

          Wendy, this fix is waited for a long time by many people and is really a major issue.
          Is it really not possible to work on this for 2.4 ?

          Show
          Damien Lecan added a comment - Wendy, this fix is waited for a long time by many people and is really a major issue. Is it really not possible to work on this for 2.4 ?
          Hide
          Geoffrey Wiseman added a comment -

          This is a real thorn in our sides. Seems like we may have to disable this plugin.

          Show
          Geoffrey Wiseman added a comment - This is a real thorn in our sides. Seems like we may have to disable this plugin.
          Hide
          Vincent Siveton added a comment -

          MJAVADOC-197 could be a workaround for this issue.

          Show
          Vincent Siveton added a comment - MJAVADOC-197 could be a workaround for this issue.
          Hide
          Vincent Siveton added a comment -

          MJAVADOC-197 is the only workaround that we could propose at this time.

          Show
          Vincent Siveton added a comment - MJAVADOC-197 is the only workaround that we could propose at this time.
          Vincent Siveton made changes -
          Resolution Fixed [ 1 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          Fix Version/s 2.5 [ 14120 ]
          Hide
          Antonio Petrelli added a comment -

          Closed as fixed?
          This bug is not fixed, there is only a workaround!
          And anyway, we need to publish aggregated javadoc in Tiles when releasing it through the release plugin.
          Our workaround is installing the tagged version (tagged using release:prepare) before running release:perform.

          So please reopen this bug, or close it as "won't fix", "fixed" is misleading.

          Show
          Antonio Petrelli added a comment - Closed as fixed? This bug is not fixed, there is only a workaround! And anyway, we need to publish aggregated javadoc in Tiles when releasing it through the release plugin. Our workaround is installing the tagged version (tagged using release:prepare) before running release:perform. So please reopen this bug, or close it as "won't fix", "fixed" is misleading.
          Vincent Siveton made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Vincent Siveton added a comment -

          As requested

          Show
          Vincent Siveton added a comment - As requested
          Vincent Siveton made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]
          Vincent Siveton made changes -
          Link This issue is related to MNG-3023 [ MNG-3023 ]
          Vincent Siveton made changes -
          Link This issue depends upon MNG-3283 [ MNG-3283 ]
          Hide
          Vincent Siveton added a comment -

          As requested on dev@ by Antonio

          Show
          Vincent Siveton added a comment - As requested on dev@ by Antonio
          Vincent Siveton made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Won't Fix [ 2 ]
          Vincent Siveton made changes -
          Fix Version/s 2.5 [ 14120 ]
          Hide
          Shibu Gope added a comment -

          This problem still persist with version 2.5. I tried both aggregate configurations and even defined javadoc only at module level but still it tries to download dependent snapshot modules which are not built yet.

          Show
          Shibu Gope added a comment - This problem still persist with version 2.5. I tried both aggregate configurations and even defined javadoc only at module level but still it tries to download dependent snapshot modules which are not built yet.
          Hide
          Shibu Gope added a comment -

          Can someone explain what is the workaround?

          Show
          Shibu Gope added a comment - Can someone explain what is the workaround?
          Hide
          Antonio Petrelli added a comment -

          I think that the workaround in MJAVADOC-197 refers to the failOnError flag:
          http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#failOnError

          Show
          Antonio Petrelli added a comment - I think that the workaround in MJAVADOC-197 refers to the failOnError flag: http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#failOnError
          Hide
          Shibu Gope added a comment -

          It is still failing the build if javadoc is run in aggregate mode. I set the <failOnError>false</failOnError> but it still fails.

          Show
          Shibu Gope added a comment - It is still failing the build if javadoc is run in aggregate mode. I set the <failOnError>false</failOnError> but it still fails.
          Hide
          Antonio Petrelli added a comment -

          Tested on Tiles 2.2.0 snapshot (never published).
          Upgrading to Javadoc plugin 2.6 and using the "aggregate" goal, it seems to work even if the snapshot was never built.

          Show
          Antonio Petrelli added a comment - Tested on Tiles 2.2.0 snapshot (never published). Upgrading to Javadoc plugin 2.6 and using the "aggregate" goal, it seems to work even if the snapshot was never built.
          Hide
          Antonio Petrelli added a comment -

          The fix might be due to MJAVADOC-181.

          Show
          Antonio Petrelli added a comment - The fix might be due to MJAVADOC-181 .
          Damien Coraboeuf made changes -
          Link This issue relates to MNG-3685 [ MNG-3685 ]
          Hide
          Damien Coraboeuf added a comment -

          This issue could be due to MNG-3685 defect.

          Show
          Damien Coraboeuf added a comment - This issue could be due to MNG-3685 defect.
          Vincent Siveton made changes -
          Link This issue is duplicated by MJAVADOC-260 [ MJAVADOC-260 ]
          Vincent Siveton made changes -
          Link This issue is duplicated by MJAVADOC-264 [ MJAVADOC-264 ]
          Francis De Brabandere made changes -
          Link This issue is related to MJAVADOC-276 [ MJAVADOC-276 ]
          Hide
          Francis De Brabandere added a comment -

          Not sure if this is a dupe or just related

          Show
          Francis De Brabandere added a comment - Not sure if this is a dupe or just related
          Hide
          Patrick M.J. Roth added a comment -

          We have the same behaviour, as soon as the aggregate goal is called. In our case, this arrives in the default lifecycle, since we attached the javadoc plugin to the verify phase through a profile. When the profile is activated, the build fails. Furthermore, failOnError , as decribed in http://jira.codehaus.org/browse/MJAVADOC-197, has no effect here.

          We use maven 3.0.4 and javadoc plugin 2.8.1.

          I attach a project which should allow to reproduce the problem.

          Show
          Patrick M.J. Roth added a comment - We have the same behaviour, as soon as the aggregate goal is called. In our case, this arrives in the default lifecycle, since we attached the javadoc plugin to the verify phase through a profile. When the profile is activated, the build fails. Furthermore, failOnError , as decribed in http://jira.codehaus.org/browse/MJAVADOC-197 , has no effect here. We use maven 3.0.4 and javadoc plugin 2.8.1. I attach a project which should allow to reproduce the problem.
          Hide
          Patrick M.J. Roth added a comment - - edited

          The problem should be reproducible with the project in mymobiliartest.zip

          Show
          Patrick M.J. Roth added a comment - - edited The problem should be reproducible with the project in mymobiliartest.zip
          Patrick M.J. Roth made changes -
          Attachment mymobiliartest.zip [ 59227 ]
          Hide
          Emmanuel Lécharny added a comment -

          The problem is that for some reason, the Javadoc plugin is run before the other projects are built, therefore as the associated jars are not present in the ocal .m2 repository.

          For instance, while trying to release MINA, the version of each project is bumped up from XXX-SNAPSHOT to XXX, so the associated jars are not present before the end of the build. Sadly, the javadoc plugin is trying to fetch those jars, with no success.

          If I do a mvn clean install just after the release:prepare, the a second run of the mvn release:prepare now works.

          This is a real problem...

          Show
          Emmanuel Lécharny added a comment - The problem is that for some reason, the Javadoc plugin is run before the other projects are built, therefore as the associated jars are not present in the ocal .m2 repository. For instance, while trying to release MINA, the version of each project is bumped up from XXX-SNAPSHOT to XXX, so the associated jars are not present before the end of the build. Sadly, the javadoc plugin is trying to fetch those jars, with no success. If I do a mvn clean install just after the release:prepare, the a second run of the mvn release:prepare now works. This is a real problem...
          Hide
          Elliot Metsger added a comment -

          @Emmanuel: We're probably going to be hit with this bug soon as well. Every time we use the release plugin, we get clobbered with this. Is there a tractable solution? If I had some pointers I'd be willing to attempt a fix. I'm reasonably familiar with the Maven codebase.

          Show
          Elliot Metsger added a comment - @Emmanuel: We're probably going to be hit with this bug soon as well. Every time we use the release plugin, we get clobbered with this. Is there a tractable solution? If I had some pointers I'd be willing to attempt a fix. I'm reasonably familiar with the Maven codebase.
          Hide
          Emmanuel Lécharny added a comment -

          The problem is most certainly that the javadoc plugin is run too soon. It's most certainly my fault, as I had :

          <profile>
          <id>apache-release</id>

          <build>
          <plugins>
          <plugin>
          <artifactId>maven-javadoc-plugin</artifactId>
          <executions>
          <execution>
          <phase>package</phase> <<<---------------This is BAD !

          <goals>
          <goal>javadoc</goal>
          </goals>
          <configuration>
          <aggregate>true</aggregate>

          so the javadoc plugin was run before the jars were deployed locally (this is done during the install phase, accordingly to the defaultLifeCycle )

          I changed that to :
          <profile>
          <id>apache-release</id>

          <build>
          <plugins>
          <plugin>
          <artifactId>maven-javadoc-plugin</artifactId>
          <executions>
          <execution>
          <phase>install</phase> <<<----------------------Done after the install phase. Should work

          <goals>
          <goal>javadoc</goal>
          </goals>
          <configuration>
          <aggregate>true</aggregate>
          </configuration>
          </execution>
          </executions>
          </plugin>

          As a matter of fact, we do exactly the same thing for the jxr-plugin :

          <plugin>
          <artifactId>maven-jxr-plugin</artifactId>
          <configuration>
          <aggregate>true</aggregate>
          </configuration>

          <executions>
          <execution>
          <phase>install</phase> <<<<-----------------------------Smart !!!

          I haven't run the release with such a modification, but I'm confident that it solves my issue...

          Show
          Emmanuel Lécharny added a comment - The problem is most certainly that the javadoc plugin is run too soon. It's most certainly my fault, as I had : <profile> <id>apache-release</id> <build> <plugins> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <phase>package</phase> <<<---------------This is BAD ! <goals> <goal>javadoc</goal> </goals> <configuration> <aggregate>true</aggregate> so the javadoc plugin was run before the jars were deployed locally (this is done during the install phase, accordingly to the defaultLifeCycle ) I changed that to : <profile> <id>apache-release</id> <build> <plugins> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <phase>install</phase> <<<----------------------Done after the install phase. Should work <goals> <goal>javadoc</goal> </goals> <configuration> <aggregate>true</aggregate> </configuration> </execution> </executions> </plugin> As a matter of fact, we do exactly the same thing for the jxr-plugin : <plugin> <artifactId>maven-jxr-plugin</artifactId> <configuration> <aggregate>true</aggregate> </configuration> <executions> <execution> <phase>install</phase> <<<<-----------------------------Smart !!! I haven't run the release with such a modification, but I'm confident that it solves my issue...
          Hide
          Elliot Metsger added a comment -

          @Emmanuel: many thanks for this advice. We'll definitely attempt this approach!

          Show
          Elliot Metsger added a comment - @Emmanuel: many thanks for this advice. We'll definitely attempt this approach!
          Hide
          Emmanuel Lécharny added a comment -

          Actually, the pb is that doing an aggregate Javadoc this way, you won't get the javadoc jar deployed on your repo. It will just be generated in target (not sure though, I haven't run it).

          Another idea would be to create a new module, run at the end, which contains the javadoc plugin. This is pretty much the same as the way we create a global aggregated distribution in a multi-module project.

          I'm even wondering if it would not be a good idea to move the javadoc execution in the distribution module...

          Show
          Emmanuel Lécharny added a comment - Actually, the pb is that doing an aggregate Javadoc this way, you won't get the javadoc jar deployed on your repo. It will just be generated in target (not sure though, I haven't run it). Another idea would be to create a new module, run at the end, which contains the javadoc plugin. This is pretty much the same as the way we create a global aggregated distribution in a multi-module project. I'm even wondering if it would not be a good idea to move the javadoc execution in the distribution module...
          Hide
          Patrick M.J. Roth added a comment -

          I already tried

          <execution>
          <phase>verify</phase>
          </execution>

          but it didn't solve the issue.

          As far as I have seen, a component (javadoc plugin?, site plugin? or more probably the maven framework itself) checks the dependencies very early in the life cycle, independently of the phase at which the javadoc is executed.

          I also tried to build with --fail-never. In that case modules are built, but the build itself is reported as failed. The site itself is not generated.

          However the following works:
          mvn install javadoc:aggregate

          This could mean that the javadoc plugin is not involved.

          Show
          Patrick M.J. Roth added a comment - I already tried <execution> <phase>verify</phase> </execution> but it didn't solve the issue. As far as I have seen, a component (javadoc plugin?, site plugin? or more probably the maven framework itself) checks the dependencies very early in the life cycle, independently of the phase at which the javadoc is executed. I also tried to build with --fail-never. In that case modules are built, but the build itself is reported as failed. The site itself is not generated. However the following works: mvn install javadoc:aggregate This could mean that the javadoc plugin is not involved.
          Hide
          Emmanuel Lécharny added a comment -

          The 'verify' phase comes before the jars are deployed on your repo :

          ...
          post-integration-test
          verify
          install
          deploy

          from http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html, Default Lifecycle

          Show
          Emmanuel Lécharny added a comment - The 'verify' phase comes before the jars are deployed on your repo : ... post-integration-test verify install deploy from http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html , Default Lifecycle
          Hide
          Patrick M.J. Roth added a comment -

          Sorry, you're right Emmanuel, 'verify' is before 'install'. But I also tried 'install', with no success.

          I have debugged what happens in my case. I've seen that an exception is thrown when the jar can't be downloaded. In the catch clause it is then checked if the jar is part of the project. Since it is the case, the exception is ignored and a warning is written (something like "can't find dependency, but appears to be part of reactor, try to go further").

          As you see, maven can recover from such an error. However, a file with extension .lastUpdated is written in place of the jar not found. If the same jar is searched for once more, then an new error is thrown and the build fails definitely.

          I didn't analyze further, because it apears to me to be quite complex. Furthermore, I can circumvent the problem by running 'install' and 'site' in two separate commands.

          Show
          Patrick M.J. Roth added a comment - Sorry, you're right Emmanuel, 'verify' is before 'install'. But I also tried 'install', with no success. I have debugged what happens in my case. I've seen that an exception is thrown when the jar can't be downloaded. In the catch clause it is then checked if the jar is part of the project. Since it is the case, the exception is ignored and a warning is written (something like "can't find dependency, but appears to be part of reactor, try to go further"). As you see, maven can recover from such an error. However, a file with extension .lastUpdated is written in place of the jar not found. If the same jar is searched for once more, then an new error is thrown and the build fails definitely. I didn't analyze further, because it apears to me to be quite complex. Furthermore, I can circumvent the problem by running 'install' and 'site' in two separate commands.

            People

            • Assignee:
              Vincent Siveton
              Reporter:
              Damien Lecan
            • Votes:
              51 Vote for this issue
              Watchers:
              47 Start watching this issue

              Dates

              • Created:
                Updated: