Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22252

Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • maven-plugin
    • Jenkins 1.532.2, Task Scanner plugin installed, Maven 3.2.1 tool installation configured

      If in the above environment you run the attached job, you will get

      [TASKS] Scanning folder '.../workspace' for files matching the pattern '**/*.java' - excludes: 
[TASKS] Found 2 files to scan for tasks
Found 0 open tasks.
[TASKS] File encoding has not been set in pom.xml, using platform encoding UTF-8, i.e. build is platform dependent (see <a href="http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding">Maven FAQ</a>).
java.io.IOException: Remote call on channel failed
	at hudson.remoting.Channel.call(Channel.java:731)
	at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167)
	at com.sun.proxy.$Proxy7.execute(Unknown Source)
	at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:201)
	at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:326)
	at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:317)
	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:628)
	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:610)
	at hudson.maven.Maven3Builder$JenkinsEventSpy.onEvent(Maven3Builder.java:306)
	at org.apache.maven.eventspy.internal.EventSpyDispatcher.onEvent(EventSpyDispatcher.java:108)
	at org.apache.maven.eventspy.internal.EventSpyExecutionListener.mojoSucceeded(EventSpyExecutionListener.java:131)
	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87)
	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:227)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
	at org.jvnet.hudson.maven3.launcher.Maven31Launcher.main(Maven31Launcher.java:132)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
	at jenkins.maven3.agent.Maven31Main.launch(Maven31Main.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:134)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:69)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:328)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.LinkageError: Failed to load com.google.common.collect.AbstractMapBasedMultimap
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:326)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:270)
	at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1622)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1622)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
	at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1706)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
	at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
	at hudson.remoting.UserRequest.perform(UserRequest.java:98)
	... 7 more
Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322)
	... 38 more

        1. config.xml
          3 kB

          [JENKINS-22252] Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap

          Jesse Glick created issue -

          Jesse Glick added a comment -

          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.)

          Jesse Glick added a comment - 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.)
          Jesse Glick made changes -
          Component/s Original: tasks-plugin [ 15498 ]
          Component/s Original: analysis-core [ 15709 ]
          Assignee Original: Ulli Hafner [ drulli ]
          Ulli Hafner made changes -
          Link New: This issue is related to JENKINS-19096 [ JENKINS-19096 ]

          Ulli Hafner added a comment - - edited

          I'm not sure if JENKINS-19096 is related, with Maven 3.1 the findbugs plugin does not work anymore due to a class loading problem. It works without problems in 3.0.

          Ulli Hafner added a comment - - edited I'm not sure if JENKINS-19096 is related, with Maven 3.1 the findbugs plugin does not work anymore due to a class loading problem. It works without problems in 3.0.

          Ulli Hafner added a comment -

          BTW: Maven 2.x jobs also don't work with my plug-ins anymore: JENKINS-15490.

          I think most of these bug will be fixed if we get a better isolation of the classes in our Jenkins plug-ins and in the Maven process.

          Ulli Hafner added a comment - BTW: Maven 2.x jobs also don't work with my plug-ins anymore: JENKINS-15490 . I think most of these bug will be fixed if we get a better isolation of the classes in our Jenkins plug-ins and in the Maven process.
          Ulli Hafner made changes -
          Link New: This issue is related to JENKINS-15490 [ JENKINS-15490 ]

          Mr Cinquero added a comment -

          Maybe a bit off-topic, but better class isolation? Wouldn't that imply even more or at least not less memory footprint? Jenkins is already wasting quite a lot of memory with its plugin design. I think it would be better to have a proper integration test system for the plugins and dump the class isolation.

          Mr Cinquero added a comment - Maybe a bit off-topic, but better class isolation? Wouldn't that imply even more or at least not less memory footprint? Jenkins is already wasting quite a lot of memory with its plugin design. I think it would be better to have a proper integration test system for the plugins and dump the class isolation.

          Jesse Glick added a comment -

          @marc321 class loader isolation is needed to allow different versions of software to coëxist (not just a testing issue). There is no real alternative in Java. Anyway the memory usage from duplicate class loading is relatively minor; this is far down the list of concerns.

          Jesse Glick added a comment - @marc321 class loader isolation is needed to allow different versions of software to coëxist (not just a testing issue). There is no real alternative in Java. Anyway the memory usage from duplicate class loading is relatively minor; this is far down the list of concerns.

          Mr Cinquero added a comment -

          Maybe. However, I have always been using maven-enforcer-plugin with the dependency convergence enforcement enabled (http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html) and never had any issues with it. I just forced dependencies to use higher versions of some lib dependencies and it worked....

          Mr Cinquero added a comment - Maybe. However, I have always been using maven-enforcer-plugin with the dependency convergence enforcement enabled ( http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html ) and never had any issues with it. I just forced dependencies to use higher versions of some lib dependencies and it worked....

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            69 Vote for this issue
            Watchers:
            77 Start watching this issue

              Created:
              Updated:
              Resolved: