|
||||||||
|
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/d/optout.
AbstractMapBasedMultimap was introduced in Guava 14 (bundled in Maven 3.2.1); AbstractMultimap is present in the Guava 11 used by Jenkins core. So presumably the Maven plugin is allowing Guava 11 to “leak through” from core into the effective classpath for the Maven agent. Then when AbstractMapBasedMultimap is loaded from 14, parent-first delegation causes it to look for its superclass in the wrong class loader. I think this is a bug in the Maven plugin: for Guava at least it should delegate to Maven’s lib/*.jar preferentially. (There is no general rule that I can think of, because some other libraries bundled with core may well be needed from plugins loading code in the Maven build agent.)