arturobernalg opened a new pull request, #13727: URL: https://github.com/apache/maven/pull/13727
JAnsi stopped being a maven-core dependency when it was migrated to JLine (Migrate from JAnsi to JLine, introduce MessageBuilderFactory, #11874), but maven-core/src/main/resources/META-INF/maven/extension.xml still declares org.fusesource.jansi:jansi as an exportedArtifact and org.fusesource.jansi.* as an exportedPackage. DefaultArtifactFilterManager builds its classpath exclusion filter from these declarations (via CoreExports), so any plugin that declares jansi as its own dependency silently has it stripped from its realm, even though maven-core does not actually provide it. This broke at least the jkube Kubernetes Maven plugin on 3.10.0. Added ExtensionDescriptorBuilderTest#testCoreExtensionDescriptorHasNoStaleExports, which loads maven-core's own production extension.xml from the classpath and asserts none of its exports mention jansi -- fails on the current descriptor, passes once the stale entries are removed. Full maven-core suite, checkstyle and spotless pass locally. --- To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0) check one of the following: - [x] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](https://www.apache.org/licenses/LICENSE-2.0) - [x] I hereby declare that I have filed an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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]
