-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Javadoc fails with "cannot access InternalFutureFailureAccess" #6776
Comments
FYI, the version of Maven I'm using:
|
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. |
And I still saw the same error and the same modulepath. So the problem may be that Guava isn't a real module (#2970) and thus doesn't declare its dependency on ...OK, I built and installed a We were trying to release only one version of (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?
It 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 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 Anyway, it looks like I note your observation of "THIS SEEMS TO TRIGGER THE BUG" in your 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:
(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 |
Ah! Actually updating to 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. |
… to 1.0.2 to prepare for a release (which we'll then need to update Guava to use). I chose an `Automatic-Module-Name` over an actual `module-info`, even for this dependency-free artifact, because [I can do that without requiring JDK 9+ for builds](#6549 (comment)). Granted, there would be relatively little harm in requiring JDK 9+ for `failureaccess` builds, since `failureaccess` isn't part of our normal build process. (Guava's build pulls an already released version of `failureaccess`.) Still, it's possible that someone is building both Guava _and_ `failureaccess` with JDK 8, so it may be nice not to break that workflow. Plus, I'm not sure that a proper module definition buys us much (relative to `Automatic-Module-Name`) when we have no deps? Still, I am a bit tempted, if only to try to shake out remaining issues that `module-info` might cause our users. This CL is progress toward fixing #6776 (or "toward working around a Maven bug," if you prefer). It's also a tiny bit of progress toward modularizing Guava (#2970), since `failureaccess` is one of its existing unmodularized dependencies. RELNOTES=Added an `Automatic-Module-Name` to `failureaccess`, [Guava's one strong runtime dependency](https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies). PiperOrigin-RevId: 573236700
… to 1.0.2 to prepare for a release (which we'll then need to update Guava to use). I chose an `Automatic-Module-Name` over an actual `module-info`, even for this dependency-free artifact, because [I can do that without requiring JDK 9+ for builds](#6549 (comment)). Granted, there would be relatively little harm in requiring JDK 9+ for `failureaccess` builds, since `failureaccess` isn't part of our normal build process. (Guava's build pulls an already released version of `failureaccess`.) Still, it's possible that someone is building both Guava _and_ `failureaccess` with JDK 8, so it may be nice not to break that workflow. Plus, I'm not sure that a proper module definition buys us much (relative to `Automatic-Module-Name`) when we have no deps? Still, I am a bit tempted, if only to try to shake out remaining issues that `module-info` might cause our users. This CL is progress toward fixing #6776 (or "toward working around a Maven bug," if you prefer). It's also a tiny bit of progress toward modularizing Guava (#2970), since `failureaccess` is one of its existing unmodularized dependencies. RELNOTES=Added an `Automatic-Module-Name` to `failureaccess`, [Guava's one strong runtime dependency](https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies). PiperOrigin-RevId: 573930127
This prevents a `gpg: signing failed: Timeout` error during release. This lets us continue our progress on #6776. RELNOTES=n/a PiperOrigin-RevId: 573990130
This prevents a `gpg: signing failed: Timeout` error during release. This lets us continue our progress on #6776. RELNOTES=n/a PiperOrigin-RevId: 573995200
Fixes #6776 RELNOTES=n/a PiperOrigin-RevId: 573991633
Fixes #6776 RELNOTES=n/a PiperOrigin-RevId: 573991633
Fixes #6776 RELNOTES=n/a PiperOrigin-RevId: 573991633
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:
$ git clone git@github.com:archiecobbs/guava-javadoc-bug.git $ cd guava-javadoc-bug $ mvn
The problem goes away if you remove the
<Automatic-Module-Name>${automatic.module.name}</Automatic-Module-Name>
in the JAR plugin configuration.The text was updated successfully, but these errors were encountered: