Mess around more with Javadoc and Maven toolchains: #7591
Merged
+96
−59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=60&v=4){kind=small}
- Use Temurin over Zulu. Per [advice](#7492 (comment)) from @ben-manes, LTS versions of Temurin [come pre-installed](https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#Hosted-Tool-Cache). - But be willing to run with any JDK of the appropriate version that's available, rather than requiring Zulu. (Not that this makes a huge difference, given that we'll still *download* Temurin JDKs. I didn't think this through much. I guess you can now at least avoiding downloading a Temurin JDK if you make sure you already have enough JDKs registered and you pass `-Dtoolchain.skip`.) - Make the test jobs fail [if they need to download a needed JDK](https://github.com/linux-china/toolchains-maven-plugin#how-to-skip-toolchains-maven-plugin-on-cicd-platform) because we didn't already put that one in place with `setup-java`. (Our other CI jobs, which publish snapshots to Sonatype and regenerate snapshot Javadoc, will continue to tolerate missing JDKs. We could change them, too, by making their scripts pass through options to identify the run as a CI run.) This should help us keep our versions in sync, and it should prevent us from silently falling back to slower downloads, per b/334979149. - Use Java 21 to generate Javadoc (as that's the best we can do now without [further trouble](#6790 (comment))). I've made sure to make Java 21 available through `setup-java`, including for generating Sonatype snapshots, which [do include Javadoc](https://oss.sonatype.org/content/repositories/snapshots/com/google/guava/guava/HEAD-jre-SNAPSHOT/). Plus, use Java 23 for the Maven VM itself there (so as to standardize on the same version as we already use for the Maven VM itself during our test workflows as of cl/711476575). - Fix a few Javadoc warnings, leaving behind only [a handful that we can't easily do anything about](#6790 (comment)). - Download Java 11 only when it is required. Currently, that's for JDiff and for our Gradle integration tests. There is a decent chance that this CL will break something, possibly not until we run the snapshot steps after submission... :) RELNOTES=n/a PiperOrigin-RevId: 711746683
copybara-service
bot
force-pushed
the
test_711520051
branch
from
63794e4 to
c171b9c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mess around more with Javadoc and Maven toolchains:
setup-java. (Our other CI jobs, which publish snapshots to Sonatype and regenerate snapshot Javadoc, will continue to tolerate missing JDKs. We could change them, too, by making their scripts pass through options to identify the run as a CI run.) This should help us keep our versions in sync, and it should prevent us from silently falling back to slower downloads, per b/334979149.setup-java, including for generating Sonatype snapshots, which do include Javadoc. Plus, use Java 23 for the Maven VM itself there (so as to standardize on the same version as we already use for the Maven VM itself during our test workflows as of cl/711476575).There is a decent change that this CL will break something, possibly not until we run the snapshot steps after submission... :)
RELNOTES=n/a