[MINOR] Persist the Maven build cache between CI runs

[slachiewicz]

What is the purpose of the pull request

.mvn/extensions.xml enables maven-build-cache-extension, but the cache never survives a CI run, so it currently costs us the bookkeeping and buys nothing.

actions/setup-java with cache: maven persists ~/.m2/repository. The extension writes to ~/.m2/build-cache, which is not covered, so it starts empty every time. This is visible in any recent build log — ten modules, ten Local build was not found by checksum lines, zero restores:

[INFO] Local build was not found by checksum ... for org.apache.xtable:xtable
[INFO] Local build was not found by checksum ... for org.apache.xtable:xtable-api
... (10 in total, no "Found cached build" anywhere)

Every run therefore rebuilds and retests all ten modules from scratch, including for pull requests that touch only the website, a workflow file, or a single leaf module.

Brief change log

• Restore ~/.m2/build-cache before the Maven build and save it afterwards, in .github/workflows/mvn-ci-build.yml

Notes on the specific shape of the change:

• actions/cache/restore + actions/cache/save are used instead of plain actions/cache so that only main writes an entry. Pull requests restore from main's cache rather than each branch filling the repository-wide 10 GB cache budget — which matters here, since cached module output includes the shaded xtable-utilities bundle and would otherwise compete with the ~/.m2/repository cache for the same quota.
• Source Build Check is deliberately left alone. It passes -Dmaven.build.cache.enabled=false and skips cache: maven on purpose, to prove the source release builds without prebuilt artifacts; caching there would defeat the check.
• Restores are keyed on the extension's own input checksums, so a module is only restored when its inputs match exactly. A run can always be forced to ignore the cache with -Dmaven.build.cache.enabled=false.

Verify this pull request

This pull request is a build/CI infrastructure change with no production code touched.

Verified locally that the extension does restore once the directory survives, which is the premise of the change. Two consecutive ./mvnw clean install -ntp -B -DskipTests runs on Temurin 11, with ~/.m2/build-cache deleted before the first:

	cold	warm
Total time	2:05 min	2.9 s
Found cached build	0 / 10 modules	10 / 10 modules
Local build was not found by checksum	10	0

The warm run reports Skipping plugin execution (cached) for surefire:test, apache-rat:check, lombok:delombok and the rest, which is where the bulk of CI time goes.

That measurement is the fully-unchanged best case. In practice the saving depends on what a pull request touches: a change to xtable-core still rebuilds and retests core and everything downstream of it, while a website, workflow, or docs-only change should hit on all ten. The workflow YAML itself is not a build input, so this change does not invalidate module checksums.

Also worth a separate look: the extension is pinned at 1.1.0 and 1.2.3 was released 2026-05-22.