Closed archiecobbs closed 1 year ago
FYI, the version of Maven I'm using:
$ mvn --version
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /opt/homebrew/Cellar/maven/3.9.4/libexec
Java version: 17.0.8.1, vendor: Homebrew, runtime: /opt/homebrew/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "13.5.2", arch: "aarch64", family: "mac"
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.3.0:enforce (enforce-java) on project guava-javadoc-bug:
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion failed with message:
[ERROR] Detected JDK version 11.0.20-1 (JAVA_HOME=/usr/local/buildtools/java/jdk11) is not in the allowed range [17,).
Thank you for that. I am not so good at following directions on the first try... :)
If this is Guava's fault, it's very likely my fault in one way or another. I'll poke around a little and see if anything jumps out to me.
<debug>true</debug>
on the maven-javadoc-plugin
configuration
shows:
--module-path
'/usr/local/google/home/cpovirk/.m2/repository/com/google/errorprone/error_prone_annotations/2.21.1/error_prone_annotations-2.21.1.jar:/usr/local/google/home/cpovirk/.m2/repository/com/google/guava/guava/32.1.3-jre/guava-32.1.3-jre.jar:/usr/local/google/home/cpovirk/.m2/repository/org/checkerframework/checker-qual/3.37.0/checker-qual-3.37.0.jar:/tmp/tmp.2ZFSJIuik9/guava-javadoc-bug/module/target/guava-javadoc-bug-module-1.0.0.jar'
InternalFutureFailureAccess
is part of failureaccess
, a dependency of Guava. That artifact isn't a part of the modulepath. I would hope that maven-javadoc-plugin
automatically pulls in transitive dependencies normally, but just to be safe, I added:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>failureaccess</artifactId>
<version>1.0.1</version>
</dependency>
And I still saw the same error and the same modulepath.
So the problem may be that Guava isn't a real module (https://github.com/google/guava/issues/2970) and thus doesn't declare its dependency on failureaccess
. It's also possible that failureaccess
itself would have to be made into a proper module (or perhaps just acquire an Automatic-Module-Name
, since it doesn't have deps).
...OK, I built and installed a failureaccess-1.0.2
locally with <Automatic-Module-Name>com.google.common.util.concurrent.internal</Automatic-Module-Name>
, and the modulepath picked up failureaccess
, and the error went away.
We were trying to release only one version of failureaccess
ever, but obviously we failed at that once already. I think that a change that doesn't touch any .class files should be fine, but I'll probably hold off until I have a moment to think about this a little more deeply.
(Thanks for the report!)
Wow, that's pretty subtle. Thanks for quickly figuring out what's going on.
I'm curious though who is really to blame for this bug. Can this be considered a Maven bug?
maven-compiler-plugin
compiles them just finemaven-javadoc-plugin
failsIt seems like if you can compile something, you should also be able to javadoc it....
More support for this view: there doesn't seem to be any way to configure the maven-javadoc-plugin
to workaround this problem - which means this failure can't be blamed on a mere misconfiguration.
Your thoughts?
You will not have to twist my arm too hard to get me to admit that Maven might have bugs :)
Speaking of which, I can't seem to get maven-compiler-plugin
to output its command line to a file, even when I set debugFileName
and fork
and debug
and verbose
(the latter two of which sound unrelated, but just to be safe), whether I set that in the parent pom or the child... :) But the plugin prints more info when I pass -X
, so I'll go with that.
Anyway, it looks like maven-compiler-plugin
is passing -classpath
, not --module-path
.
I note your observation of "THIS SEEMS TO TRIGGER THE BUG" in your maven-jar-plugin
config. My guess would that maven-javadoc-plugin
looks at the jar (which of course maven-compiler-plugin
can't because the jar doesn't exist at that point), sees the Automatic-Module-Name, and goes into "modules mode."
And oh, look at this: https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-707. I have only skimmed it, but it immediately seems very clearly related:
The next release of the javadoc plugin (3.6.0) will offer a new switch (
legacyMode
) which should make this work for you. please try with<legacyMode>true</legacyMode>
either with the current snapshot or the next release.
(There's also a workaround given that could work today. It involves moving things to different phases. That seems like a shame.)
We could still try to give failureaccess
a module name, since that's probably a good idea, anyway. But the problem you're seeing should go away if you're willing to set legacyMode
on the new maven-javadoc-plugin
release.
Ah! Actually updating to 3.6.0
fixes the problem, even without legacyMode
:
diff --git a/pom.xml b/pom.xml
index 7faae4a..72e3f56 100644
--- a/pom.xml
+++ b/pom.xml
@@ -21,6 +21,7 @@
<java.version>17</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<guava.version>32.1.3-jre</guava.version>
+ <maven-javadoc-plugin.version>3.6.0</maven-javadoc-plugin.version>
</properties>
<!-- Versions for dependencies used by multiple modules -->
So maybe this is really just MJAVADOC-769.
The fix is now released as part of 33.0.0.
Thanks!
I am not convinced that this is ultimately Guava's fault, but Guava seems to be causing the problem.
My builds fail during Javadoc because of Guava, like this:
To reproduce the bug, first verify you are using JDK 17. Then:
The problem goes away if you remove the
<Automatic-Module-Name>${automatic.module.name}</Automatic-Module-Name>
in the JAR plugin configuration.