Maven 4 prefix filtering blocks artifact resolution from third-party repositories #12433

Summary

Maven 4's prefix-based artifact filtering (using prefixes.txt / .meta/prefixes.txt) prevents artifacts from being resolved from third-party repositories that should contain them. The prefix filter rejects the download path before the repository is even tried, resulting in ArtifactFilteredOutException.

In Maven 3, all configured repositories were tried in order. In Maven 4, the prefix filter short-circuits resolution, and when an artifact's path doesn't match the prefix list for a repository, it's skipped entirely — even if the repository actually has the artifact.

Affected projects (from Maven 4 compatibility testing)

cloudstack

Artifacts org.opensaml:opensaml:2.6.6 and org.connectbot.jbcrypt:jbcrypt:1.0.0 are absent from Maven Central but available in the Jenkins CI repository (repo.jenkins-ci.org). The prefix filter blocks the path:

prefixes: Path org/connectbot/jbcrypt/jbcrypt/1.0.0/jbcrypt-1.0.0.jar NOT allowed from repo.jenkins-ci.org
prefixes: Path org/opensaml/opensaml/2.6.6/opensaml-2.6.6.jar NOT allowed from repo.jenkins-ci.org.public

ws-axiom

Artifacts with osgi.bundle groupId (e.g., osgi.bundle:java_cup.runtime:0.10.0.v201005080400) are blocked by prefix filters on all configured repositories, even though the Eclipse p2 repository should serve them:

prefixes: Path osgi/bundle/java_cup.runtime/0.10.0.v201005080400/java_cup.runtime-0.10.0.v201005080400.jar NOT allowed from central
prefixes: Path osgi/bundle/java_cup.runtime/0.10.0.v201005080400/java_cup.runtime-0.10.0.v201005080400.jar NOT allowed from apache.snapshots
Could not find artifact osgi.bundle:java_cup.runtime:jar:0.10.0.v201005080400 in eclipse_2021_09

Analysis

The prefix filtering optimization is correct for well-known repositories like Maven Central, but may be too aggressive for third-party or specialized repositories (Jenkins CI, Eclipse p2, custom Nexus) where:

• The repository may not publish a prefixes.txt at all
• The auto-discovered prefix list may be incomplete
• The repository layout may differ (e.g., p2/OSGi repositories)

In Maven 3, these artifacts were found by simply trying the repository. The prefix filter should perhaps fall back to attempting the download when no prefix file is available for a repository, or when the repository explicitly opts out of prefix filtering.

Questions

• Is this the intended behavior for repositories without a prefixes.txt?
• Should there be a way to disable prefix filtering per-repository (e.g., <prefixes>false</prefixes> in repository configuration)?
• Is the auto-discovery of prefixes for third-party repos generating false negatives?