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

Hi all,

Thanks Tamas — that pins down what I couldn’t trace at the policy level. The Maven 3 → Maven 4 default change from WARN to FAIL (with MNG-5728 <https://issues.apache.org/jira/browse/MNG-5728> context) explains the empirical IT difference exactly: my IT was hitting FAIL by default, not WARN.

That recalibrates a few things:

The immediate fix landed in apache/maven-ear-plugin#505 <https://github.com/apache/maven-ear-plugin/pull/505> (merged yesterday by Sylwester, thanks), using <checksumPolicy>ignore</checksumPolicy> to override the Maven 4 default. The rc-5 lanes on maven-ear-plugin master should be green now.
maveniverse/checksum 0.2.0 <https://github.com/maveniverse/checksum/releases/tag/release-0.2.0> (with the new directory mojo) looks like a strong candidate for cleaning up the broader pattern: the 12 Maven plugins that currently ship <checksumPolicy>ignore</checksumPolicy> in their IT settings.xml could in principle migrate to “fixtures ship proper .sha1 / .md5 companions” and drop the workaround. Whether that’s a single coordinated effort or per-plugin opportunistic is a separate discussion — flagging it here as a follow-up candidate, not a commitment.
PR #1922 <https://github.com/apache/maven-resolver/pull/1922> (relax WARN.onNoMoreChecksums to log+return) doesn’t directly fix the IT failure under Maven 4’s FAIL default, but it enables a sensible intermediate state: once it lands, IT settings.xml could migrate from <checksumPolicy>ignore</checksumPolicy> (silent bypass) to <checksumPolicy>warn</checksumPolicy> (observable warnings, build proceeds) — a step on the way to fixtures eventually shipping proper checksums.
One housekeeping note on my original framing: the “Resolver 2 vs 1.9” phrasing was empirical, not source-traced. Cross-checking the policy classes confirms what Tamas also found — WarnChecksumPolicy, AbstractChecksumPolicy, ChecksumValidator.validate(), and the BasicRepositoryConnector metadata-loop are essentially byte-identical between maven-resolver-1.9.27 <https://github.com/apache/maven-resolver/releases/tag/maven-resolver-1.9.27> and maven-resolver-2.0.13 <https://github.com/apache/maven-resolver/releases/tag/maven-resolver-2.0.13>. The behavioural difference is in maven-resolver-provider default-policy wiring on the Maven 4 side, not in Resolver code.

Regards,
Gerd



> On 15. Jun 2026, at 08:49, Tamás Cservenák <[email protected]> wrote:
> 
> Howdy,
> 
> So, this is a mvn3 vs mvn4 change: 
> Maven4 defaults to FAIL checksum policy, while Maven3 is WARN.
> And in current days, this change makes sense.
> 
> Perso, I'd rather have all the IT checksums as well, instead to distinguish
> in some artificial way the transport.
> 
> Hence, the new mojo added:
> https://github.com/maveniverse/checksum/releases/tag/release-0.2.0
> 
> Thanks
> T
> 
> 
> 
> On Sat, 13 Jun 2026 at 23:01, Gerd Aschemann <[email protected] <mailto:[email protected]>> wrote:
>> 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.
>> 
>> 
>> WarnChecksumPolicy.onNoMoreChecksums() throws like fail policy on missing checksums · Issue #1920 · apache/maven-resolver
>> github.com
>>  <https://github.com/apache/maven-resolver/issues/1920>WarnChecksumPolicy.onNoMoreChecksums() throws like fail policy on missing checksums · Issue #1920 · apache/maven-resolver <https://github.com/apache/maven-resolver/issues/1920>
>> github.com <https://github.com/apache/maven-resolver/issues/1920>
>> 
>> 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] <mailto:[email protected]> -- http://www.aschemann.net <http://www.aschemann.net/>
>> 

--
Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- [email protected] -- http://www.aschemann.net