It broke various plugins with missing classes ( org.slf4j.helpers.MarkerIgnoringBase, org.slf4j.helpers.MessageFormatter ) like:
* net.java.truelicense:truelicense-maven-plugin (2.3.4)
* com.github.eirslett:frontend-maven-plugin (0.0.20, 0.0.22)
* maven-antrun-plugin with the cobertura ant task
* org.mortbay.jetty:jetty-maven-plugin (7.6.16.v20140903)
The first step here is deprecating the publicly accessible method that allows
plugins to inject dependencies. The only plugin I currently know of that does
this is the cobertura-maven-plugin. Looking at that plugin it appears the user
can specify the cobertura dependency for the instrumentation process but if
they do not the plugin attempts to inject the dependency. I believe the path
forward here is making sure these types of plugins instruct their users to
add the dependency explicitly.
I'm going to try and create a call-graph for all of Maven Central with my
first test to see if I can accurately detect all usages of MavenProject.setDependencyArtifacts
of artifact in Maven Central.
Some plugins, e.g., cobertura-maven-plugin, use ${plugin.artifacts}
to setup classpath of externally launched jvms and they expect slf4j
to be available among plugin dependencies. At the same time slf4j
is already part of maven core runtime and it needs to be filtered
out from plugin and build extension realms to avoid duplicate classes
on classpath.
The fix is to move core artifact filtering from plugin dependency
resolver to class realm manager. This way ${plugin.artifacts} still
includes all compile/runtime scoped plugin dependencies but runtime
classpath only has plugin unique artifacts.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
read ${maven.projectBasedir}/.mvn/extensions.xml and create core
extensions realms during maven runtime bootstrap. this required
short-lived bootstrap plexus container to resolve extensions.
individual extensions realms are wired to maven.ext realm according
to META-INF/maven/extension.xml exported packages specification
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
javax.inject.* and org.slf4j.* packages were already exported, but
corresponding artifacts were not. this resulted in same classes
present in multiple classlaoders and caused hard-to-troubleshoot
build failures in some cases.
Signed-off-by: Igor Fedorenko <ifedorenko@apache.org>
