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

Classpath cleared after maven-javadoc-plugin:javadoc

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Duplicate
    • Affects Version/s: 2.5, 2.6, 2.6.1, 2.7
    • Fix Version/s: 2.8
    • Labels:
      None
    • Environment:
      mac OSX 10.6.4

      Description

      Repro Case:

      • I have a war based maven configuration with the maven-javadoc-plugin as copied below.
      • > mvn jetty:run

      Result:

      • When jetty loads, every servlet fails to load, the first is always java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener followed by null pointers and CNFE's on every servlet.

      When i take out the execution of the maven-javadoc-plugin everything works?! My only guess is that when the javadoc plugin runs, it does something with the classpath such that when jetty runs it doesn't have what it needs to find all the classes correctly.

      My javadoc configuration is as follows:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>javadoc</goal>
            </goals>
            <phase>generate-resources</phase>
          </execution>
        </executions>
      </plugin>

        Issue Links

          Activity

          Bryan Campbell created issue -
          Hide
          Bryon Jacob added a comment -

          a workaround, which might help indicate the source of the problem, is to use the "aggregate" goal instead of the "javadoc" goal.

          it appears that the two goals do essentially the same thing, except that the aggregate goal is run as an aggregator plugin:
          http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html
          http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html
          http://docs.codehaus.org/display/MAVEN/Aggregator+Plugins

          which has the benefit that the execution is always forked, so the classpath munging doesn't affect the rest of your lifecycle. Looking at the source, you can see that the "aggregate" goal simply extends the "javadoc" goal and turns on the "aggregator" bit:
          http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AggregatorJavadocReport.html

          Looking at the wiki on Aggregator Plugins, I don't see any reason why it should be dangerous to use that on a non-aggregate project, and empirically, this seems to work around the issues Bryan mentions above.

          Show
          Bryon Jacob added a comment - a workaround, which might help indicate the source of the problem, is to use the "aggregate" goal instead of the "javadoc" goal. it appears that the two goals do essentially the same thing, except that the aggregate goal is run as an aggregator plugin: http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html http://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html http://docs.codehaus.org/display/MAVEN/Aggregator+Plugins which has the benefit that the execution is always forked, so the classpath munging doesn't affect the rest of your lifecycle. Looking at the source, you can see that the "aggregate" goal simply extends the "javadoc" goal and turns on the "aggregator" bit: http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AggregatorJavadocReport.html Looking at the wiki on Aggregator Plugins, I don't see any reason why it should be dangerous to use that on a non-aggregate project, and empirically, this seems to work around the issues Bryan mentions above.
          Hervé Boutemy made changes -
          Field Original Value New Value
          Description Repro Case:
            - I have a war based maven configuration with the maven-javadoc-plugin as copied below.
            - > mvn jetty:run

          Result:
            - When jetty loads, every servlet fails to load, the first is always java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener followed by null pointers and CNFE's on every servlet.

          When i take out the execution of the maven-javadoc-plugin everything works?! My only guess is that when the javadoc plugin runs, it does something with the classpath such that when jetty runs it doesn't have what it needs to find all the classes correctly.

          My javadoc configuration is as follows:

          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <executions>
              <execution>
                <goals>
                  <goal>javadoc</goal>
                </goals>
                <phase>generate-resources</phase>
              </execution>
            </executions>
          </plugin>
          Repro Case:
            - I have a war based maven configuration with the maven-javadoc-plugin as copied below.
            - > mvn jetty:run

          Result:
            - When jetty loads, every servlet fails to load, the first is always java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener followed by null pointers and CNFE's on every servlet.

          When i take out the execution of the maven-javadoc-plugin everything works?! My only guess is that when the javadoc plugin runs, it does something with the classpath such that when jetty runs it doesn't have what it needs to find all the classes correctly.

          My javadoc configuration is as follows:

          {code:xml}<plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <executions>
              <execution>
                <goals>
                  <goal>javadoc</goal>
                </goals>
                <phase>generate-resources</phase>
              </execution>
            </executions>
          </plugin>{code}
          Hide
          Hervé Boutemy added a comment -

          can you provide a sample project with instructions to reproduce the problem?

          Show
          Hervé Boutemy added a comment - can you provide a sample project with instructions to reproduce the problem?
          Hide
          Hervé Boutemy added a comment -

          could you be hit by MJAVADOC-279?
          ie do you have dependencies with classifiers?

          Show
          Hervé Boutemy added a comment - could you be hit by MJAVADOC-279 ? ie do you have dependencies with classifiers?
          Hide
          Hervé Boutemy added a comment -

          after searching more deeply, one way to confirm the issue is to check MPIR-223
          please try to use 2.1.1 or 2.2 of maven-project-info-report-plugin: they should not cause the problem
          but 2.1, 2.3 or 2.3.1 cause the problem
          one workaround is to change the plugin version
          another is to avoid dependencies report

          Show
          Hervé Boutemy added a comment - after searching more deeply, one way to confirm the issue is to check MPIR-223 please try to use 2.1.1 or 2.2 of maven-project-info-report-plugin: they should not cause the problem but 2.1, 2.3 or 2.3.1 cause the problem one workaround is to change the plugin version another is to avoid dependencies report
          Hide
          Hervé Boutemy added a comment -

          as far as I can tell, this is a consequence of MPIR-223, then a duplicate of MJAVADOC-279

          if you're still having an issue when removing MPIR dependencies report, please open another Jira issue with a test project to reproduce the problem

          Show
          Hervé Boutemy added a comment - as far as I can tell, this is a consequence of MPIR-223 , then a duplicate of MJAVADOC-279 if you're still having an issue when removing MPIR dependencies report, please open another Jira issue with a test project to reproduce the problem
          Hervé Boutemy made changes -
          Resolution Duplicate [ 3 ]
          Assignee Herve Boutemy [ hboutemy ]
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 2.8 [ 16433 ]
          Hervé Boutemy made changes -
          Link This issue duplicates MJAVADOC-279 [ MJAVADOC-279 ]
          Hervé Boutemy made changes -
          Link This issue is related to MPIR-223 [ MPIR-223 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 11:56:47 UTC 2015 [ 1428235007093 ]
          Mark Thomas made changes -
          Link This issue is related to MPIR-223 [ MPIR-223 ]
          Mark Thomas made changes -
          Workflow jira [ 12722536 ] Default workflow, editable Closed status [ 12762294 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 00:11:46 UTC 2015 [ 1428279106587 ]
          Mark Thomas made changes -
          Link This issue is related to MPIR-223 [ MPIR-223 ]
          Mark Thomas made changes -
          Workflow jira [ 12960087 ] Default workflow, editable Closed status [ 12996963 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          170d 22h 2m 1 Hervé Boutemy 01/May/11 10:34

            People

            • Assignee:
              Hervé Boutemy
              Reporter:
              Bryan Campbell
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development