Impossible to aggregate javadoc if snapshot never built

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.

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

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.

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.

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

testcase included flag to yes.

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

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 ?

Reopen since checkMissingArtifactsInReactor() doesnt take care of classifier.

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

> 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...

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

Good luck

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

"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.

Still doesn't work with classifiers

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

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!

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

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 ?

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

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, same problem as me with classifiers.

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 ?

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

MJAVADOC-197 could be a workaround for this issue.

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

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.

As requested

As requested on dev@ by Antonio

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.

Can someone explain what is the workaround?

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

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

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.

The fix might be due to MJAVADOC-181.

This issue could be due to MNG-3685 defect.

Not sure if this is a dupe or just related

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.

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

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...

@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.

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...

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

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...

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.

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

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.