Audit docs/developer/release: remove the retired Maven Central steps, fail on drift, and ship what the release builds - #2097

Found while tracing how a release reaches Maven Central.

release_push.py steps 5b and 5c walk the releaser through the OSSRH Nexus
staging UI -- "click on iogithubeisop-XXXX", "Click close at the top", "Copy
the URL of the closed artifacts (in the bottom pane)" -- and then ask them to
paste that URL back into the script. The Central Portal has no close step and
no such panes, so anyone following the script looks for a button that no
longer exists. Adopting the one-call automation removes these steps rather
than requiring them to be reworded.

A release has to bump the version in 34 places across 12 files besides
build.gradle: the examples under docs/examples, and several places in the
manual and the webpage. They are consistent today, and keeping them so is
manual; a missed one leaves the manual telling readers to depend on a version
that is no longer newest.

docs/examples/publish-smoketest builds against publishToMavenLocal, so it
checks the artifacts the build would publish but not that a deployment
arrived. Once nightly snapshots exist, pointing it at the published snapshot
repository would catch a broken publication on the day it breaks.

And the documented release command hardcodes one maintainer's GPG key, which
reads as the value to use rather than as the releaser's own.

README-eisop.md now says that the key is the releaser's own, that the upload
is staged and not live until published, where that is done, and that other
files carry the version too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The target rewrote files that no longer exist and keyed off marker
comments that pages no longer carry. Ant's <replaceregexp> only prints
"The following file is missing" and still reports BUILD SUCCESSFUL, and a
marker regex that matches nothing is not an error at all, so both kinds of
drift were silent.

Gone from the tree: docs/manual/checkerframework.gradle,
build-common.properties, checker/build.properties. Wrong path:
checkerQuickStartPage pointed into docs/manual/ rather than docs/.
Absent markers: checker-framework-version and compiler-version on
docs/checker-framework-webpage.html.

Drop those five rules, fix the quick-start path, and add require-file and
require-marker macros that assert every file and marker up front, so the
target now fails before rewriting anything. Also drop checker.tutorial and
checker.release, unused in this target, and the release.properties entries
left with no reader.

docs/checker-framework-quick-start.html still advertised
checker-framework-2.1.7.zip, having missed every release since the path
broke; bring it to the current release and fix its javac path, which had
bin/checker inverted relative to every other document.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ents

The release scripts and Renovate were both bumping docs/examples, and
fighting. Renovate rewrites a pom property in place and drops marker
comments around it -- it did that to MavenExample-framework-all/pom.xml in
PR #2017. The Ant target keyed off those same markers, including in
update-and-copy-maven-example, which sets the version on the copy the
Maven sanity check compiles. Had Renovate reached MavenExample/pom.xml
first, that check would have gone on compiling the previous release and
still passed.

Give the examples to Renovate alone: drop both example rules from
update-checker-framework-versions, match the <checkerFrameworkVersion>
element rather than markers when preparing the sanity-check copy, and
remove the now-vestigial markers from MavenExample/pom.xml.

Two renovate.json changes make that reliable. Every Renovate edit ever
made to the example Gradle builds was a plugin version; the eisop version
in them was last bumped by Dependabot, removed in PR #1997. These builds
hold it in a variable (an ext.versions map entry, or a plain def), so add
an explicit customManagers regex rather than rely on Renovate's Gradle
variable resolution. Second, the repository-wide minimumReleaseAge of 7
days delayed our own artifact a week behind every release, so set it to 0
for io.github.eisop and give it its own PR.

Separately, checker-includes had drifted the same silent way, and an Ant
include pattern that matches nothing is not an error either. README.html
was renamed away in 2015, so no README shipped in the distribution at
all. "Make class name and file name the same" moved the units-extension
qualifiers into qual/ and renamed Demo.java in 2020, so that example
shipped its Makefile, README and Expected.txt and not one Java source --
the shipped Makefile refers to files that are not in the zip. Verified on
the published site, whose newest release is 3.49.3-eisop1: under
/cf/checker-framework-3.49.3-eisop1/examples/units-extension/, README is
200 while UnitsExtensionDemo.java is 404, and README.md is 404.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Maven Central does not pin a signing key to a namespace; it only checks
that each signature verifies against a public key it can fetch from a
keyserver. Several maintainers can therefore each sign with their own key,
and nothing in this repository has to change when a new one starts
releasing. Only the documentation implied otherwise, by presenting one
maintainer's key as the value to pass.

Move the key out of the command line and into the releaser's own
~/.gradle/gradle.properties, next to the Portal tokens already documented
there, so the release command names no key at all. Fail the signing task
with an explicit message when signing.gnupg.keyName is unset: gpg would
otherwise fall back to whichever secret key happens to be its default,
which may not be one Central can verify. Snapshots are unsigned, so the
check does not affect them.

Record the release-process findings from this audit in
maven-central-publishing.md: two web pages that the release still
rewrites but that nothing publishes (the main one has already been ported
to the website repository's cf-template.md, minus its Dataflow Framework
bullet), and the fact that the website is still on 3.49.3-eisop1 because
nothing runs the site generator as part of a release.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The snapshot-publishing workflow was written against generic examples
rather than this repository's own workflows, so it selected the temurin
JDK and pinned actions/checkout, actions/setup-java, and
gradle/actions/setup-gradle at v4.  ci.yml and dependency-submission.yml
use zulu and much newer pins, and Renovate has been bumping only those
two, because this file exists on a branch.

Switch to zulu and pin checkout@v7, setup-java@v6.0.1, and
setup-gradle@v6.3.0, matching the other workflows as of this merge.  The
v4 pins of checkout and setup-java run on an older Node runtime that
GitHub warns about.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#1060 asked to move publishing to the Central Portal and JReleaser.  The
first half is already true, and this branch's evaluation rejected the second:
the plugins that speak the Portal API natively configure publications, and
this build has 18 hand-tuned ones.  The issue is closed as superseded, so it
belongs in this release's list.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>