We will be able to actually merge PR directly there, since the source of truth for `gh-pages` is GitHub! But of course this will be confusing, since it's different from how changes to Guava `master` work and since both of those differ from how our other projects work... :)
Some history:
- 6d0a979155
- fb02c3434a
- https://github.com/google/guava/issues/7597#issuecomment-2840049761
RELNOTES=n/a
PiperOrigin-RevId: 852813933
It turns out that the configuration has to [exist in the `gh-pages` branch instead](6d0a979155).
(This is a rollback of 3a8737936c.)
PiperOrigin-RevId: 852333862
This allows+requires us to [replace each release's Javadoc directory with a Javadoc archive file](407e30a02f).
As noted in that commit, this saves a ton of time when switching branches: I'm now seeing ~3s instead of ~30s to switch to `gh-pages` and ~2s instead of ~7s to switch back to `master`. (It probably slows down downloading the entire repo's history, though, since the repo history now contains all the original files *plus* the archives that contain them all. I can fix that if I ever rewrite the whole history of `gh-pages`.)
I'd raised this possibility back in https://github.com/google/guava/issues/7597#issuecomment-2840049761.
To make this take effect, I'll need to update https://github.com/google/guava/settings/pages to use a Source of "GitHub Actions" instead of "Deploy from a branch." This matches what we already do for JSpecify.
I notice that it may be a little weird for our `master` branch to have a GitHub Actions setup that pushes to our `gh-pages` branch, which then has a GitHub Actions setup that deploys that branch. I suspect that it at least makes sense to have two separate actions, since we sometimes push to the `gh-pages` branch outside the context of a push to `main`—notably, when we perform a release.
(One thing that we could consider is the idea of merging `gh-pages` into `master`, presumably under a `docs` directory. But I think that's been possible forever, and we haven't done it. That's probably for the best, since it would make a shallow clone of `master` slow because of all the Javadoc.)
RELNOTES=n/a
PiperOrigin-RevId: 851409347
As usual, Guava continues to be usable from Java 8; this CL changes only the build tools that we use to produce it.
Compare e4f311803c.
RELNOTES=n/a
PiperOrigin-RevId: 812751582
...as contemplated in cl/788538710 and elsewhere.
(Background: We carried much or all of the `sonatype-oss-release` configuration over from the old `oss-parent` in changes like cl/492304151.)
This (I hope) accomplished two classes of goals:
- By enabling\[*\] `central-publishing-maven-plugin` by default, we enable it even for _snapshot_ deployment. Advantages:
- It lets the plugin automatically disable `maven-deploy-plugin`. (Compare cl/805973207 for Truth.) And _that_ allows us to remove the configuration of https://central.sonatype.com/repository/maven-snapshots, which isn't needed by `central-publishing-maven-plugin` but which has been required by `maven-deploy-plugin`, which has no default. (Compare cl/805870501 for Truth.)
- It causes us to begin deploying snapshots through the new Central system.
- To make that work, we need to [set `server-id` to `central`, not `sonatype-central-staging`](https://github.com/google/auto/issues/1965#issuecomment-3299992670), since `central-publishing-maven-plugin` uses a different ID than we had `maven-deploy-plugin` set up to use. (Compare cl/807814773 for Truth.) Since `central` is also what is used for non-snapshot releases, we could view this is a baby step toward performing non-snapshot releases on GitHub CI someday.
- It ensures that non-release builds _also_ run some plugins and/or use the versions of those plugins that we have requested. (For _some_ projects, we've already been running these plugins, or we've at least kept versions consistent because we use `dependencyManagement` or other explicit versions.) Advantages and fallout:
- We now get coverage for Javadoc during CI. (We've wanted this before. We went so far as to implement it for Truth in cl/509829752, and I've wanted it multiple times for Compile-Testing: cl/494805776, cl/802247571.) This change led to errors for Compile-Testing (again!) under JDK 8, so I fixed those by making the `--add-exports` configuration conditional.
- We need to make a change to some of our CI configurations: Our snapshot-publishing builds request Javadoc and sources explicitly at the command line (with `mvn source:jar javadoc:jar deploy`). With this CL's changes, Maven would try to build Javadoc and sources twice—once for the command-line request and once for the new configuration we have. The fix for that is to stop making the explicit request. (Compare cl/807772725 for Truth, somewhat cl/572327204 for Guava, and maybe sorta kinda cl/536746714 for jimfs.)
- We address the following warning, which https://github.com/google/guava/pull/7961 had proposed to address another way but for which I'd merely added a TODO in cl/804600714:
```
[WARNING] Some problems were encountered while building the effective model for com.google.guava:guava-tests:jar:999.0.0-HEAD-jre-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.sonatype.central:central-publishing-maven-plugin is missing. @ line 103, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
```
\[*\] "Enabling" may or may not be the right word. The `central-publishing-maven-plugin` plugin still doesn't _run_ unless someone actually runs `mvn deploy`. The only difference in output that that plugin change causes for a typical build is this, which I assume is related to its usage of [`<extensions>true</extensions>`](https://maven.apache.org/guides/mini/guide-using-extensions.html):
```
[INFO] Inspecting build with total of 6 modules
[INFO] Installing Central Publishing features
```
I left `maven-gpg-plugin` alone because we don't want to request that users enter their signing keys during snapshot deployment, let alone during normal builds. Another option would be to move it out of the profile but to disable it by default, with the profile becoming responsible for undoing the disablement. (Or we could stop using a profile entirely in favor of passing a flag to set a property to do the same.) That would theoretically be nice because it helps with the "same version number" goal discussed above. But given that I never recall having run `maven-gpg-plugin` outside a release setting, I doubt that that matters in practice.
(If we're lucky, this CL's changes to Auto specifically might be enough to deal with https://github.com/google/auto/issues/1965.)
Plus: I removed some redundant declarations of `<groupId>org.apache.maven.plugins</groupId>`, which is the default for plugins. (We had been including it inconsistently.) Compare cl/793718324.
Finally: In Guava, I removed a "Guava Documentation Site" entry. This was added back in cl/29254221, but I can't immediately figure out why, and I see no other references to its `guava-site` in either the main or `gh-pages` branch of our repo, nor anywhere internal to Google. I'm hoping that it's at least become unnecessary in the past decade-plus. (The changes in this CL at least have no effect on the _jars_ that we produce as output.)
Bonus Maven curiosity: I noticed that we have been getting a Javadoc warning:
```
[WARNING] Javadoc 1.4+ doesn't support the -1.1 switch anymore. Ignore this option.
```
This appears to be [a known issue](https://lists.apache.org/thread/k15x84xvj0tv9gngy2426cpm83d85l61).
RELNOTES=n/a
PiperOrigin-RevId: 807859217
As usual, Guava continues to be usable from Java 8; this CL changes only the build tools that we use to produce it.
RELNOTES=n/a
PiperOrigin-RevId: 744082109
This includes:
- setting up Dependabot _at all_ for a few projects
- dropping GitHub Actions from weekly to monthly for the rest
My feeling on the latter is that GitHub Actions upgrades never feel urgent: Even when GitHub stopped supporting old versions of `actions/cache`, they gave plenty of warning. I'd also note that I don't think we've had trouble much (if ever?) with upgrades to GitHub Actions, so there's even less reason to fear batching of updates than usual. Given that, we might as well try to batch together as many updates as we can so as to marginally reduce toil. (And if an upgrade it ever truly urgent for security reasons, I expect that Dependabot would push us to it promptly, anyway, perhaps even for projects without a Dependabot config at all.)
RELNOTES=n/a
PiperOrigin-RevId: 739294702
This brings us to the newest released version, which also means that it matches the version that we use for javac, so we require one less JDK.
cl/711811272 fixed [the error we'd previously been seeing with JDK 23](https://github.com/google/guava/issues/6790#issuecomment-2489156480).
(Also, if someone has a JDK 23 already installed and skips our auto-downloading, use it even if it's not Temurin. I'd made this change for most toolchain usages in cl/711746683, but I missed the usage one for Javadoc.)
RELNOTES=n/a
PiperOrigin-RevId: 711839263
- Use Temurin over Zulu. Per [advice](https://github.com/google/guava/issues/7492#issuecomment-2439753364) 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](https://github.com/google/guava/issues/6790#issuecomment-2489156480)). 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](https://github.com/google/guava/issues/6790#issuecomment-2489215760).
- 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
This lets us use whatever Java version we want\[1\] for executing Maven itself—and thus for executing any plugins that aren't toolchain-aware. (I even hacked up our toolchain configuration to run tests under Java 24, and it worked.) I've changed our CI to do that, too, by always using Java 23. (This makes the explicit choice of Java 23 for _javac_ redundant under CI, as well as on our Google workstations. However, it can be useful for anyone who builds Guava locally while having an older JDK as the default version.)
Notably, that means that we can use a new version (like Java 23) for running the GWT plugin, which lets us upgrade to GWT 2.12.1 (cl/711417161), which uses an Eclipse compiler with bytecode version 55 (Java 11)\[2\]. (This means that users who build `guava-gwt` locally with Java 8 will need to [upgrade their build JDK to at least Java 11](https://github.com/google/guava/issues/6549)—or skip building `guava-gwt` if they don't need it.)
That GWT upgrade is in turn necessary in order for us to be able to use use [JSpecify annotations](https://github.com/jspecify/jspecify/issues/239) from our GWT artifact.
In theory, this could also prepare us for further changes, like more easily running tests under multiple versions during our release process (in addition to how we already do so for CI), though there are already other ways of doing that by hacking up our release script or `pom.xml`. And I'm not sure that I'd really want to do that, anyway. (See also some notes that I've added to cl/639128020.)
I also did some related cleanup:
- Our `--no-module-directories` configuration probably became Just Wrong back in cl/655647768: It should be based on the version that we use to build Javadoc (which is currently always 11), not the version that Maven is running under. It probably mostly doesn't matter because we probably mostly don't try to run Javadoc under other versions, but I'd like to be able to do so, so this is a step forward.
- `-Djava.security.manager=allow` is not necessary now that we've cleaned up our usages of `SecurityManager`. (And that's fortunate, as it seems difficult to [active a profile based on a range of values of an arbitrary "my test JRE version" property](https://issues.apache.org/jira/browse/MNG-3328), as opposed to activate it based on the JDK that Maven is running under.)
Fixes https://github.com/google/guava/issues/7492 (by making `setup-java` download all the toolchains that we need)
\[1\] I mean, I suspect that Maven support lags new JDKs somewhat, and I've seen problems with other versions (as documented in cl/488902996). But at least we don't have to use the same Java version for executing Maven itself as we do for executing tests.
\[2\] That was causing this error:
```
[INFO] --- gwt:2.10.0:compile (gwt-compile) @ guava-gwt ---
Error: [ERROR] Unexpected internal compiler error
[INFO] java.lang.UnsupportedClassVersionError: org/eclipse/jdt/internal/compiler/classfmt/ClassFormatException has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
[INFO] at java.lang.ClassLoader.defineClass1(Native Method)
[INFO] at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
[INFO] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[INFO] at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
[INFO] at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
[INFO] at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
[INFO] at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
[INFO] at java.security.AccessController.doPrivileged(Native Method)
[INFO] at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
[INFO] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
[INFO] at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:488)
[INFO] at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:464)
[INFO] at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:426)
[INFO] at com.google.gwt.dev.Precompile.validate(Precompile.java:145)
[INFO] at com.google.gwt.dev.Compiler.compile(Compiler.java:184)
[INFO] at com.google.gwt.dev.Compiler.compile(Compiler.java:143)
[INFO] at com.google.gwt.dev.Compiler.compile(Compiler.java:132)
[INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:110)
[INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
[INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
[INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:113)
```
RELNOTES=n/a
PiperOrigin-RevId: 711476575
