Classpath cleared after maven-javadoc-plugin:javadoc

Details

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.

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.

Bryon Jacob
added a comment - 27/Jan/11 08:29 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.

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.

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.

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

Hervé Boutemy
added a comment - 30/Apr/11 16:25 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

Hervé Boutemy
added a comment - 01/May/11 10:34 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