Maven 3.9.12: Plugin prefix resolution re-downloads group metadata on every invocation

[vasilii-bolgar-212]

Affected version

3.9.12 (not present in 3.9.11)

Bug description

Plugin prefix resolution introduced in #11197 re-downloads group-level maven-metadata.xml for all plugin groups on every Maven invocation.

The debug log reveals the cause:

[DEBUG] Could not find metadata org.springframework.boot/maven-metadata.xml in local (/path/to/.m2/repository)
[DEBUG] Could not find metadata com.diffplug.spotless/maven-metadata.xml in local (/path/to/.m2/repository)
[DEBUG] Could not find metadata org.jacoco/maven-metadata.xml in local (/path/to/.m2/repository)
...

The prefix resolution code looks for maven-metadata.xml in the local repository, but the Maven Resolver stores these files as maven-metadata-<repoId>.xml (e.g. maven-metadata-central.xml). Since the plain filename is never found locally, Maven downloads from the remote repository on every run.

With Maven 3.9.11, mvn spotless:apply completes near-instantly. With 3.9.12, the same command downloads ~15 group-level metadata files every time (one per plugin group declared in the parent POM's <pluginManagement>).

Steps to reproduce

1. Use a parent POM that declares multiple plugins in <pluginManagement> (e.g. spring-boot-starter-parent, which declares plugins for spring-boot, jacoco, flyway, kotlin, jooq, liquibase, graalvm, cyclonedx, git-commit-id, etc.)

2. Add a plugin that uses a prefix, e.g. Spotless:

<plugin>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <version>3.4.0</version>
</plugin>

3. Run mvn spotless:apply twice in a row.

Expected behavior

Second run should use locally cached metadata. This is how 3.9.11 behaves.

Actual behavior

Both runs download group-level maven-metadata.xml for every plugin group:

Downloading from central: .../org/springframework/boot/maven-metadata.xml
Downloading from central: .../com/diffplug/spotless/maven-metadata.xml
Downloading from central: .../org/jacoco/maven-metadata.xml
Downloading from central: .../io/github/git-commit-id/maven-metadata.xml
Downloading from central: .../org/cyclonedx/maven-metadata.xml
Downloading from central: .../org/jooq/maven-metadata.xml
Downloading from central: .../org/jetbrains/kotlin/maven-metadata.xml
Downloading from central: .../org/flywaydb/maven-metadata.xml
Downloading from central: .../org/liquibase/maven-metadata.xml
Downloading from central: .../org/graalvm/buildtools/maven-metadata.xml
Downloading from central: .../org/mortbay/jetty/maven-metadata.xml
Downloading from central: .../org/apache/maven/plugins/maven-metadata.xml
Downloading from central: .../org/codehaus/mojo/maven-metadata.xml

Debug output shows:

[DEBUG] Could not find metadata org.springframework.boot/maven-metadata.xml in local (/path/to/.m2/repository)

But the file does exist locally as maven-metadata-<repoId>.xml:

$ ls ~/.m2/repository/org/springframework/boot/maven-metadata-*
maven-metadata-central.xml
maven-metadata-central.xml.sha1

Impact

On slower repository mirrors, this adds significant overhead (2+ minutes) to every Maven command that uses plugin prefixes.

Workarounds

• Use Maven 3.9.11 (e.g. via Maven Wrapper: mvn wrapper:wrapper -Dmaven=3.9.11)
• Use full plugin coordinates: mvn com.diffplug.spotless:spotless-maven-plugin:3.4.0:apply

Related

• Different and unexpected behavour on invoking goals #11067 - Original issue about prefix resolution downloading all plugins
• Simplify prefix resolution #11197 - PR that changed prefix resolution to use metadata only
• Something is off with prefix resolution #11252 - Regression when metadata is not available
• Fix plugin prefix resolution when metadata is not available from repository #11290 - Fix for above (included in 3.9.12)

[cstamas]

Can you try with 3.9.14, which is currently the latest bugfix release?

Nope, am wrong, will not help. Problem is that spotless plugin is invalid, in a way, it does not publish G level metadata (hence, is never cached as it does not exists).

[cstamas]

This is addressed in upcoming Maven 3.10.x, unsure will we do anything in 3.9.x line with this.

[slawekjaranowski]

This is addressed in upcoming Maven 3.10.x, unsure will we do anything in 3.9.x line with this.

We need check in 4.x only

[cstamas]

Yes, we need fix in maven 4 as well