WarnChecksumPolicy.onNoMoreChecksums() throws like fail policy on missing checksums

[ascheman]

Behavior

When a remote repository transfer yields no checksum data (the artifact is
fetched but neither .sha1 nor .md5 companion exists for the resource),
AbstractChecksumPolicy.onNoMoreChecksums() raises a
ChecksumFailureException unconditionally:

@Override
public void onNoMoreChecksums() throws ChecksumFailureException {
    throw new ChecksumFailureException("Checksum validation failed, no checksums available");
}

WarnChecksumPolicy and FailChecksumPolicy inherit this method without
overriding it, so warn raises the same hard exception as fail in this
code path. The current behavior is pinned by
WarnChecksumPolicyTest.testOnNoMoreChecksums, so it is intentional /
documented state — but the consequence for users is that only
<checksumPolicy>ignore</checksumPolicy> effectively lets transfers proceed
when checksum data is absent, regardless of how the policy is named.

Where this matters in practice

The file:// test-fixture pattern hits this every time. Apache plugins have
been working around it by setting <checksumPolicy>ignore</checksumPolicy>
in src/it[/mrm]/settings.xml. Snapshot from
gh api search/code 2026-06-10:

Added during Maven 4 API migration (June 2024)

• apache/maven-clean-plugin — 2da14745 ([MCLEAN-123] Switch to Maven 4 API and the new api maven-clean-plugin#20)
• apache/maven-compiler-plugin — 9dc957dc
• apache/maven-deploy-plugin — 88ce1593
• apache/maven-project-info-reports-plugin — a44cc8ab ([MPIR-455] - add support for multi-release JARs. maven-project-info-reports-plugin#70)
• apache/maven-resources-plugin — 3716fc1a ([MRESOURCES-308] Switch to the Maven 4 API maven-resources-plugin#35)

The five June-2024 commits cluster within 17 days and four of their subject
lines explicitly read "Switch to Maven 4 API". This is the strongest
empirical signal that Maven 4 / Resolver 2.x made the workaround materially
more common.

Long-standing (pre Maven 4) for file:// + mock-repository-manager IT setups

• apache/maven-dependency-plugin (2014) — 1eef3011
• apache/maven-jlink-plugin (2017) — 56c529d6
• apache/maven-site-plugin (2019) — 45afac34
• apache/maven-shade-plugin (2020) — 52c476a9
• apache/maven-scripting-plugin (2021) — 028a9003
• apache/maven-install-plugin (2022) — ce0666e4

The pattern has been needed for file:// IT fixtures since at least 2014,
which is the same underlying reason — the layout expects checksums, the
file system does not provide them.

The latest example landed today as apache/maven-ear-plugin#505 (Maven 4
rc-5 IT compatibility), bringing the total to 12 plugins shipping the same
line.

Related

• [MRESOLVER-242] When no remote checksums provided by layout, transfer inevitably fails/warns #1366 (MRESOLVER-242): @cstamas 2022 raised the analogous concern for
  layout-omitted remote checksums. The patch addressed .asc / GPG
  signature handling but did not extend to the "missing on disk despite
  layout expecting checksums" case that drives the workaround above.
• Better checksum control #1782 / Better checksum control #1784 "Better checksum control" — adjacent design area.
• Checksums: lack of information #1917 "Checksums: lack of information" — adjacent.

Scope of this issue

This is a behavior observation plus cross-plugin evidence. Solution
proposals will be raised separately on dev@maven.apache.org so the
design discussion happens with the right audience and the issue stays
focused on the empirical signal.

[cstamas]

We may consider similar fix for 1.9.28. Perso, I do not plan it, but we have queued 2 PRs aside of this issue.