[DISCUSS] Resolver: checksum policy on missing checksums (#1920)

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