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
