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

Impossible to aggregate javadoc if snapshot never built

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • 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
          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.
          Hide
          Michael Osipov added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Assignee, if you think you can fix this bug anytime soon, please reopen and proceed appropriately.

          Show
          Michael Osipov added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out. Assignee, if you think you can fix this bug anytime soon, please reopen and proceed appropriately.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: