Maven 3.10.0-rc1 might be fetching (plugin?) prefixes a little too eagerly

[rpkrajewski]

Affected version

3.9.10-rc1

Bug description

Maven seems to fetch prefixes from repositories and tell you about it. Well, apparently, it felt the need to process plugins (or dependencies?) mentioned in the POM for the dependency-check plugin or one of its dependencies:

[INFO] Loaded 23704 auto-discovered prefixes for remote repository central (prefixes-central.txt)
[INFO] Loaded 74 auto-discovered prefixes for remote repository apache.snapshots (prefixes-apache.snapshots.txt)
   …
[INFO] --- dependency-check:13.0.0:check (default) @ apache-hc-filecached ---
[WARNING] Could not transfer metadata /.meta/prefixes.txt from/to jvnet-nexus-releases (https://maven.java.net/content/repositories/releases/): (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The warning is correct: maven.java.net is using a self-signed certificate. I don't think the warning is coming from code in dependency-check.

Is there any reason why Maven needs to process prefixes from a repository that is likely mentioned in a pom deep in the dependencies?

I can't wait for consumer POMs to spread through the Maven ecosystem so that this kind of historical cruft is no longer a distraction. 😀

[seanxuu]

I’d like to investigate and work on this issue.\n\nInitial findings:\n- Plugin-prefix resolution enters through MojoDescriptorCreator.findPluginForPrefix.\n- Repository metadata requests are created in DefaultPluginPrefixResolver.resolveFromRepository.\n- That resolver currently creates one metadata request for the local repository and one for every repository in PluginPrefixRequest.getRepositories().\n- DefaultPluginPrefixRequest derives those repositories from MavenProject.getRemotePluginRepositories() when a current project is present.\n\nBecause of that, I do not want to filter repositories inside the resolver prematurely: the deep dependency repositories may be introduced while project/model repositories are assembled, and filtering at the resolver layer could hide valid plugin repositories.\n\nI plan to:\n1. add a minimal regression test that captures and asserts the repository list reaching the resolver;\n2. build an integration reproduction with a deep dependency repository and a plugin-prefix lookup;\n3. trace where that repository is added to the project/plugin repository set;\n4. propose the smallest fix at the layer that introduces the unintended repository, with focused unit/integration coverage.\n\nPlease let me know if this investigation and implementation direction fits Maven’s expectations.