[MJAVADOC-769] javadoc plugin can not deal with transitive filename based modules

[jira-importer]

Henning Schmiedehausen opened MJAVADOC-769 and commented

clone this repository: https://github.com/hgschmie/mjavadoc769

This builds an artifact, a tests artifact and a javadoc jar.

When building this for Java 9+ compatibility (javadoc generate a list of modules) and using modules with Automatic-Module-Name enabled, the javadoc plugin can not access the optional dependencies:

ERROR] Exit code: 1
[ERROR] /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88: error: cannot access Provider
[ERROR]     static final class InternalBindingProvider<T> implements Provider<T> {
[ERROR]                  ^
[ERROR]   class file for javax.inject.Provider not found
[ERROR] 1 error
[ERROR] Command line was: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc -J-Xmx1024m @options @packages

Note that all other plugins (compiler, surefire) work fine. Just the javadoc plugin does not.

--add-modules
ALL-MODULE-PATH
--module-path
'/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
--patch-module
mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/9999.0-empty-to-avoid-conflict-with-guava/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
-encoding
'UTF-8'
-public
-quiet
--release
11
-bottom
'Copyright © 2023. All rights reserved.'
-charset
'UTF-8'
-d
'/Users/henning/scratch/mjavadoc769/target/apidocs'
-docencoding
'UTF-8'
-Xdoclint:none
-doctitle
'mjavadoc769 1.0-SNAPSHOT API'
-linkoffline
'https://docs.oracle.com/en/java/javase/11/docs/api' '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
-nohelp
-use
-version
-windowtitle
'mjavadoc769 1.0-SNAPSHOT API'

The javadoc plugin decides that the "javax.inject-1.jar" is added to the classpath even though it is an optional dependency of the main module. Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module path.

The reason for this may be that the jakarta module contains a module-info (hidden in META-INF/versions/9/) while the javax.inject jar does not.

However, the checker-qual (org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency is put on the module path even though it does not contain a module-info file. However, it contains an Automatic-Module-Name entry in META-INF/MANIFEST.

It seems that the javadoc plugin treats automatic dependencies with entry in the manifest different from automatic dependencies determined by filename.

---

Affects: 3.5.0

Issue Links:

• MJAVADOC-753 javadoc plugin does not find sources in auto-module when creating docs
  ("fixes")

Remote Links:

• GitHub Pull Request #227
  
• GitHub Pull Request #229
  

[jira-importer]

Henning Schmiedehausen commented

having spent some more time debugging this, this is what happens:

• the code depends on com.google.inject.Provider, which in turn extends javax.inject.Provider
• the google class is in a jar (guice-5.1.0.jar) which has an Automatic-Module-Name entry
• the javax class is in a jar that does not.

The plugin now pulls the guice jar onto the module path and patches the main module with the javax.inject jar

But the javadoc tool tries to resolve the class hierarchy of the included provider, which is the google guice provider (on the module path) and then the javax provider (patched into the main module, BUT NOT into guice). and the javadoc tool can not resolve the javax.inject class as parent for guice because it is not visible in that module.

The solution is IMHO straightforward: instead of treating jars with a module source of MANIFEST the same way as jars with a module source of MODULEDESCRIPTOR and different from module source FILENAME, they should be treated the same way as module source FILENAME (iaw patched into the main module).

[jira-importer]

Tamas Cservenak commented

Same happens in this very moment with maven-resolver master branch (e721b01be9576396e36e4167da337180b44e38e9), but situation is slightly different:

• resolver project got new Java11 module (new transport using java.net.http.HttpClient)
• Javadoc fails on it due issues described in this issue (expects maven-resolver-transport-jdk to be a module which is not)
• sadly, Automatic-Module-Names were present since eons due MRESOLVER-26, that combined with that fact that this module is javaVersion=11 triggers the issue
• while the build is ok, site generation is the one that fails
• and fix of this issue does not help, as resolver issue is about Report (site generation) and not Mojo. Basically this issue fixed Mojos, but seems Report classes duplicates same logic and suffers from same issue
• given this was triggered by addition of new Java11-level module, while build was completely okay all the time, this makes me afraid there are more differences between Mojo and Report...