Ship the front page in the release zip, and record the link scheme it depends on - #2099

The six links to search.maven.org in the manual no longer resolve: that host
answers 403 for both its /search and /artifact URLs, with a browser user agent
as well as without, while the same queries on central.sonatype.com answer 200.

Rewrite them, and drop the trailing "/jar" segment that the artifact URL form
no longer takes. Each rewritten URL was fetched to confirm it resolves. Only
the URLs change; the surrounding LaTeX is untouched.

The publishing URLs in the build were already current: snapshots go to
central.sonatype.com/repository/maven-snapshots/ and releases to the
ossrh-staging-api host, and no oss.sonatype.org or s01.oss.sonatype.org
reference remains anywhere in the tree. The occurrence in docs/CHANGELOG.md is
in a released section and is left as the historical record.

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

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>

Push steps 5a/5b/5c and 10 drove the retired OSSRH Nexus staging UI: they
told the releaser to "close" artifacts in a top pane and paste a staging
repository URL back into the script. The Central Portal has no such step.
The staging call itself could never have worked here either: it read the
signing passphrase from /projects/swlab1/checker-framework/hosting-info/,
a University of Washington path that does not exist, and signed with
checker-framework-dev@googlegroups.com rather than the releaser's key.

Maven Central publishing is in practice a separate ./gradlew publish run,
so remove those steps rather than reword them, and renumber the remaining
GitHub/website steps 1-12. Removing step 5c retires the only caller that
passed a staging repository URL, so maven_sanity_check's repo_url
parameter and add_repo_information -- which edited poms to point at
org/checkerframework artifacts -- go with it. Document the separate
publish step in README-release-process.html.

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>

Two documents were produced at release time and then discarded, because
they only ever reached the interm site directory that nothing publishes
for eisop.

docs/checker-framework-quick-start.html was kept version-correct by
update-checker-framework-versions but shipped nowhere and appeared on no
website. Add it to checker-includes so it travels in the release zip
alongside the manual, the tutorial and the CHANGELOG. Its links pointed at
https://eisop.github.io/cf/manual/#anchor, which resolves only through the
404 page's JavaScript redirect; make them site-relative so they work both
at cf/quick-start.html and in an archived cf/<release>/quick-start.html.

release_build.py already runs `make` in dataflow/manual, and
checker-framework-website-docs copies the result to the interm directory
under the very name the old front page linked to. Add it to the zip at
docs/manual/checker-framework-dataflow-manual.pdf with a fullpath
zipfileset, the mechanism already used for CFLogo.png. Because the website
generator lifts docs/manual wholesale, it surfaces at
cf/manual/checker-framework-dataflow-manual.pdf with no generator change.

eisop/eisop.github.io#103 lifts the quick-start guide to cf/quick-start.html,
restores the Dataflow Framework bullet that was dropped when the front page
was ported to cf-template.md, and links both from the front page.

checker-framework-webpage.html is deliberately left untouched here: a
follow-up PR ships it in the release zip as that release's own page, which
is the opposite of the "not published, do not edit" note that would
otherwise have landed with this commit.

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

docs/checker-framework-webpage.html is the Checker Framework's front page.
It is not published by eisop: the website generates its own from
cf-template.md in the eisop.github.io repository, a Markdown port of this
file. So this page has been version-stamped by every release and then
discarded, while its port drifted -- the port silently lost the Dataflow
Framework bullet, and nobody noticed for two years.

One template shared across every release is also a standing mismatch. A
link added for content that first ships in release N is broken on the
archived page of every release before N, permanently, not merely until the
next release. Shipping the page with the release it describes removes that
by construction, and this file is already exactly such a page: release.xml
stamps the Checker Framework version and date, and the AFU zip name and
date, into it, so it is self-contained at release time.

Add it to checker-includes. Align its links, which were still the old
typetools site layout, to the layout the zip and the website share. Because
the page is served at two depths -- as cf/index.html and as
cf/<release>/index.html -- the scheme has to be mixed: relative for what
exists at both (manual/manual.html, manual/manual.pdf, tutorial/,
api/checker-javadoc/, CHANGELOG.md, CFLogo.png) and absolute for site
singletons (/cf/<zip>, /cf/releases/releases.html, /afu/<zip>,
/afu/annotation-file-utilities.html). Checked against the live site:
manual/manual.pdf resolves at both depths while
manual/checker-framework-manual.pdf exists only at cf/. The favicon the
page references existed nowhere on the site, so ship it alongside.

The website half -- using this page and retiring cf-template.md -- needs no
release and follows separately. Until then the page rides along unused, as
the quick-start guide does.

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

The page is served at two depths, as /cf/index.html and as
/cf/<release>/index.html, so its links have to be mixed: relative for what sits
beside it at both depths, absolute for site singletons.  Making them uniformly
one or the other breaks one of the two depths, which is a trap for anyone
editing the links later.

That constraint was written down in maven-central-publishing.md, which no
longer carries the release-process archaeology.  Put it in the page it
constrains, together with the three targets that the website generator
produces rather than the zip, and a reminder that release.xml keys off the
marker comments.

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

It is served at the same two depths as the front page, so it has the same
mixed relative/absolute links and the same trap for a later editor.  Point at
the front page's comment rather than repeating the explanation.

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