Build the wrapper job with Maven 4.0.0-rc-6 - #12674
Conversation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
LGTM ✅ — Straightforward one-line version bump of the Maven wrapper from 4.0.0-rc-5 to 4.0.0-rc-6 in the CI workflow.
Verified:
- Maven 4.0.0-rc-6 is a valid, published release (confirmed on Maven Central, published 2026-07-30).
- No other files in the repository reference
4.0.0-rc-5, so no synchronized updates are needed. - The PR correctly targets the
masterbranch, consistent with prior wrapper version bumps.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of gnodet
MVNW_REPOURL pointed the wrapper at the Google Cloud mirror of Central, which lags a fresh release: apache-maven-4.0.0-rc-6-bin.zip is a 404 there while Central already serves it, so the initial-build job dies with wget: Failed to fetch https://maven-central.storage-download.googleapis.com/maven2/org/apache/maven/apache-maven/4.0.0-rc-6/apache-maven-4.0.0-rc-6-bin.zip Unsetting MVNW_REPOURL makes the wrapper fetch from Central, which always has the version this workflow just asked for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
LGTM ✅ — Re-reviewed after new commit. The second commit correctly removes the MVNW_REPOURL Google Cloud mirror override to fix the CI failure caused by mirror lag for the freshly released rc-6 distribution.
Key observations:
- The fix is well-targeted: only affects the wrapper download path, not Mimir dependency resolution which still uses the mirror via
ci-mimir-session.properties. - The wrapper download is a single-file fetch of the Maven distribution ZIP — low risk falling back to official Central.
- The commit message is excellent: includes the exact error, explains the root cause (Google mirror lag), and states the effect of the fix.
- The inline comment clearly documents the rationale for the removal.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of gnodet
The mimir session pointed dependency resolution at the same Google Cloud mirror the wrapper used, and that mirror lags a fresh release: rc-6 artifacts were still 404 there days after Central served them. Commented out rather than deleted, so restoring the mirror is one line if its sync latency stops being a problem. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Restoring the Google Cloud mirror should be uncommenting one line, not recovering it from history, if its sync latency ever stops being a problem. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
LGTM ✅ — Re-reviewed after third commit. The new commit logically completes the mirror fix by also commenting out the Mimir session mirror for dependency resolution — if the Google Cloud mirror lags for the wrapper binary, it will also lag for artifacts resolved during CI builds.
Key observations:
- Commenting out rather than deleting is the right approach — easy one-line rollback if the mirror sync latency is resolved.
- The explanatory comment documents the specific failure mode (rc-6 returning 404 on the mirror).
- Minor: file still lacks a trailing newline (pre-existing, not a regression).
- Central itself is served behind a CDN (Fastly), so the geographic/CDN benefit loss from removing the Google mirror is acceptable.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of gnodet
2 participants
4.0.0-rc-6 is released; this points the wrapper job at it.
Note: the fork has Actions disabled, so this could not be pre-verified there — it relies on ASF CI.