|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
The artifactory plugin really shouldn't put such a large number of dependencies into the plexus.core classloader. If you look at the list, it includes such things like commons http, Jackson, Guava, XPP, JDOM, commons-logging, and etc.
These jar files would be visible throughout Maven, and when a plugin attempts to load a conflicting version of one of the dependencies, they will end up picking up the version the artifactory plugin inserts. This can cause strange compatibility issues.
To minimize the classpath contamination, it should insert minimal possible, which is just one class that implements org.apache.maven.AbstractMavenLifecycleParticipant, into the plexus.core realm.
It should then create another realm as a child of the plexus.core realm, then load everything in there. The bridge class you insert into plexus.core should then delegate to the logic in the child realm.
For the time being, I'm putting a quick fix to get us back on track, but I encourage the plugin maintainers to conside r these changes.