Hi all, Filed today (labeled bug, milestone 2.0.19 — thanks Tamas), and want to surface the design question on this list before a particular shape lands.
https://github.com/apache/maven-resolver/issues/1920 WarnChecksumPolicy.onNoMoreChecksums() throws like fail policy on missing checksums · Issue #1920 · apache/maven-resolver github.com Behavior WarnChecksumPolicy.onNoMoreChecksums() inherits the unconditional throw from AbstractChecksumPolicy. Net effect: warn policy raises ChecksumFailureException on “no checksums available” just like fail, and practically only <checksumPolicy>ignore</checksumPolicy> lets transfers proceed when checksum data is absent. Empirical surface Maven plugins work around this with <checksumPolicy>ignore</checksumPolicy> in IT settings.xml for file:// fixtures. gh api search/code 2026-06-10: 11 plugins, of which 5 adopted the line in a 17-day window in June 2024 as part of “Switch to Maven 4 API” commits. apache/maven-ear-plugin#505 <https://github.com/apache/maven-ear-plugin/pull/505> brings the total to 12 today. The earlier six date back to 2014–2022 for the same file:// pattern. Full list in the issue (link in Background below). Candidate shapes I consider the following, in increasing surface impact: Override WarnChecksumPolicy.onNoMoreChecksums() — log + return. Smallest patch, scoped to warn. Drafted as apache/maven-resolver#1922 <https://github.com/apache/maven-resolver/pull/1922> (2 files, +9/-6). Transport-aware default in DefaultChecksumPolicyProvider — file:// gets a weaker effective policy automatically (the integrity-via-checksum argument doesn’t apply to local transport). New opt-in property aether.checksums.noChecksumsOutcome analogous to RRF’s noInputOutcome. Default fail, opt-in warn/ignore. Backward-compatible. Maven Core compatibility mode — top-level Maven 4 opt-in bundling Maven-3-style lenient behaviors (checksum policy on missing data, plugin-version fallback semantics, possibly others) for the rc-5 → rc-6 → GA migration window. Larger surface, addresses related friction beyond just checksums. Question Which shape fits the broader checksum-control redesign already underway in the three related issues linked in Background below? Happy to extend the draft PR with the chosen shape, or close it in favor of a maintainer-driven patch. A “Known Issue” entry in 4.0 GA release notes with the current workaround recipe would be useful as backup regardless of which shape lands when. Background apache/maven-resolver#1920 <https://github.com/apache/maven-resolver/issues/1920> — issue apache/maven-resolver#1922 <https://github.com/apache/maven-resolver/pull/1922> — draft PR (shape 1) apache/maven-ear-plugin#505 <https://github.com/apache/maven-ear-plugin/pull/505> — latest plugin workaround example (today) apache/maven-resolver#1782 <https://github.com/apache/maven-resolver/issues/1782> — Better checksum control apache/maven-resolver#1784 <https://github.com/apache/maven-resolver/issues/1784> — Better checksum control (sequel) apache/maven-resolver#1917 <https://github.com/apache/maven-resolver/issues/1917> — Checksums: lack of information apache/maven-resolver#1366 <https://github.com/apache/maven-resolver/issues/1366> — MRESOLVER-242, Tamas’s analogous 2022 issue (fixed for layout-omitted checksums but not the missing-on-disk case) gnodet/maven4-testing <https://github.com/gnodet/maven4-testing> — Guillaume’s rc-6 compatibility test push (966-project set) surfaces this kind of workaround Regards, Gerd -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- [email protected] -- http://www.aschemann.net
