Something is off with prefix resolution

[cstamas]

Affected version

master

Bug description

Subject PR #11072

Problem is demonstrated here:
https://gist.github.com/cstamas/c4ae65fb50a16fbc561ab49027ea0172

tl;dr: mvn spotless:apply stopped working with latest master

Facts:

• the plugin does not have G level metadata
• the complex heuristics did download all plugin JARs to figure out prefixes (hence was slow)
• the PR made Maven rely on metadata only

Debatable:

• is the change correct, or we need more here?
• is publishing a plugin to central without (expected) G level metadata (where prefixes are listed) ok?

[cstamas]

Seems this maven plugin is being built by Gradle, and this is yet another example of missing metadata...

[slawekjaranowski]

the same on 3.9.x

the missing meta-data is - https://repo.maven.apache.org/maven2/com/diffplug/spotless/maven-metadata.xml

[pzygielo]

Let me use this great opportunity to learn more about artifact deployment.

Which party is responsible for preparing metadata of

• G-level
• A-level
• V-level?

For A and V - I was under impression it's repository's task. As for A, the versions are updated on successful deployment I'd think.

What about G? Is that metadata deployable separately, without accompanying artifact like plugin? Can it be modified by namespace owner freely?

I bet it's written somewhere (not at https://maven.apache.org/repositories/metadata.html https://maven.apache.org/ref/3.9.11/maven-repository-metadata/ or I'm blind for that information), but maybe someone knows it already and could share the details or point to specific material?

[cstamas]

Since Maven 3.9 no client code needs to worry about metadata, it is all handled by Maven transparently. If you see any *Metadata class in client code, that is old (pre 3.9) code.

See here:
https://github.com/apache/maven/blob/maven-3.9.x/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGeneratorFactory.java

[pzygielo]

Which party is responsible for preparing metadata of

* G-level

Checked with nexus 3.85.0, and on maven-plugin (with declared <packaging>maven-plugin</packaging>) upload (pom+jar) G-level MD was generated for that.

[cstamas]

We need to solve this: not reverting, but returning "old code" in case new code fails to find the plugin or something alike... this would expose the effect of improvement the refd PR did, but would also work with broken plugins like spotless is, at the cost of downloading all the plugins POMs enlist (the original reason why prefix resolution was fixed).