I looked into this and here's why this problem is happening.

In order to interact with Maven at some pretty deep level, Artifactory plugin puts a lot of jars into Maven's "plexus.core" classpath. It does this by putting every jar that the artifactory plugin bundles in its WEB-INF/lib folder. This can be seen in the following classworlds.conf file it uses, and the actual value of m3plugin.lib that it passes when it launches JVM, such as -Dm3plugin.lib=/var/lib/jenkins/plugins/artifactory/WEB-INF/lib:

main is org.apache.maven.cli.MavenCli from plexus.core

set maven.home default ${user.home}/m2

[plexus.core]
load ${maven.home}/lib/*.jar
load ${m3plugin.lib}/*.jar

Aside from dependency jars, Jenkins plugins have its own set of code. Historically, they were packaged in the WEB-INF/classes folder of the plugin, and therefore they were not added to the above classpath before.

However, as a part of JENKINS-15120, we changed this, and now the plugin source code gets compiled into WEB-INF/lib/classes.jar and {{WEB-INF/classes} is kept empty.While somewhat dubious, this by itself wasn't a fatal problem.

As a result, now the classes.jar from artifactory plugin gets added to plexus core classpath, and when Artifactory plugin's MavenReporter implementation gets loaded into Maven JVM via remoting, it ends up resolving to the one loaded in plexus.core, instead of the dynamic classloader created by Jenkins remoting. This fails to resolve the dependencies (MavenReporter) properly, and it chokes.

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.
 
 

Reply via email to