vasilii-bolgar-212 opened a new issue, #11905: URL: https://github.com/apache/maven/issues/11905
### Affected version 3.9.12 (not present in 3.9.11) ### Bug description Plugin prefix resolution introduced in https://github.com/apache/maven/pull/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: ```xml <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 - https://github.com/apache/maven/issues/11067 - Original issue about prefix resolution downloading all plugins - https://github.com/apache/maven/pull/11197 - PR that changed prefix resolution to use metadata only - https://github.com/apache/maven/issues/11252 - Regression when metadata is not available - https://github.com/apache/maven/pull/11290 - Fix for above (included in 3.9.12) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
