WW-5719 Pin Maven distribution checksum

[cameroncrippen]

Fixes WW-5719.

Add the pinned Maven 3.9.16 ZIP's SHA-256 to the existing only-script wrapper configuration. The current launchers already verify this property before extracting fresh downloads. In response to review, this revision restores both launchers to main and removes the proposed wrapper-JAR settings. The final diff is one added properties line.

Validation on Windows with Java 17: a fresh-cache bootstrap with the correct checksum started Maven 3.9.16 successfully; a separate fresh-cache fixture using the same ordinary download and a deliberately incorrect expected checksum stopped with a checksum error before Maven started. Both launcher files match the reviewed main versions byte for byte. The ZIP's SHA-256 was independently recomputed from the downloaded archive.

Existing cached installations are not revalidated. On POSIX systems without unzip, the tar.gz fallback will not match the ZIP checksum and will fail closed, as discussed in review. Native Linux/macOS execution and upstream CI for this revision remain unverified. The earlier 4,449-test package result applies to the previous proposal; it was not rerun for this one-line change.

AI disclosure: this revision, validation and description were prepared with OpenAI Codex assistance.

[lukaszlenart]

Thanks for the careful write-up and provenance notes — I re-verified both artifacts independently (SHA-256 recomputed from Maven Central bytes, and PGP signatures check out against the Maven KEYS file), and the launchers are byte-identical to the upstream 3.3.4 script release. All good on that front.

I'd like to take the smaller route to the same goal, though. The only-script mvnw / mvnw.cmd already on main support distributionSha256Sum — the POSIX launcher verifies with sha256sum/shasum before unzipping (current mvnw:226-245), and the Windows launcher does the same with Get-FileHash before Expand-Archive (current mvnw.cmd:138-150). Both fail closed on a mismatch. So pinning the distribution needs only one line in .mvn/wrapper/maven-wrapper.properties:

distributionSha256Sum=5af3b743dd8b876b5c45da33b676251e5f1687712644abb4ee519ca56e1d89ce

Compared with switching to the script variant, that keeps:

• one pin to maintain instead of three (distributionSha256Sum + wrapperUrl + wrapperSha256Sum), and no downloaded wrapper jar to execute before Maven itself runs;
• the java-on-PATH fallback on Windows (the script variant's mvnw.cmd hard-requires JAVA_HOME);
• MVNW_REPOURL working for every download. With the script variant, the explicit wrapperUrl property overrides MVNW_REPOURL on POSIX (mvnw:222-233 reads the env var first and then the properties value wins), while mvnw.cmd does the opposite — so a mirror-only Linux/macOS host can't bootstrap. Reproduced here.

The .tar.gz fallback on hosts without unzip would fail the zip pin, which I'm fine with — that path fails closed with a clear message, unzip is present on every runner we build on, and Windows uses Expand-Archive so it isn't affected.

Could you rework the PR to:

1. revert mvnw and mvnw.cmd to the versions on main;
2. keep distributionType=only-script and add only the distributionSha256Sum line above (drop wrapperUrl / wrapperSha256Sum and the comment line, so the file stays reproducible from mvn wrapper:wrapper).

Happy to merge once that's in.

[cameroncrippen]

Thanks for the review. I have restored both launchers to main, kept distributionType=only-script, and reduced the final diff to the single requested distributionSha256Sum line. The wrapper-JAR settings and added comment are removed.

Two fresh-cache Windows Java 17 checks passed: the correct checksum starts Maven 3.9.16, and an intentionally incorrect expected checksum rejects the ordinary download before Maven starts. The launcher bytes match the reviewed base exactly. I have retained the documented POSIX limitation for systems without unzip. This revision and reply were prepared with OpenAI Codex assistance.