-
Bug
-
Resolution: Fixed
-
Blocker
-
Jenkins 1.532.2, Task Scanner plugin installed, Maven 3.2.1 tool installation configured
-
Powered by SuggestiMate
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
- is blocking
-
JENKINS-26947 Maven job stuck when slave channel get disconnected
-
- Reopened
-
- is duplicated by
-
JENKINS-30289 Tasks plugin exception
-
- Closed
-
- is related to
-
JENKINS-19096 Findbugs Reporting not working with Maven 3.1
-
- Resolved
-
-
JENKINS-15490 Analysis parsers don't work with maven 2 jobs
-
- Resolved
-
- links to
[JENKINS-22252] Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap
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....
@marc321 there's nothing a user can do, your comment is out of purpose: using Maven 3.2.1 in a Maven job type, the console is full of the described stacktrace. As explained @jglick this does not happen with Maven 3.1.1.
We experience exactly the some problem when running maven jobs with Maven 3.2.1 on Jenkins 1.558
It's also a problem with the maven-checkstyle-plugin:2.11, maven-pmd-plugin:3.0.1 and the findbugs-maven-plugin:2.5.2 plugins:
java.io.IOException: Remote call on channel failed 14:13:15 at hudson.remoting.Channel.call(Channel.java:731) 14:13:15 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167) 14:13:15 at $Proxy7.execute(Unknown Source) 14:13:15 at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:201) 14:13:15 at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:326) 14:13:15 at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:317) 14:13:15 at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:628) 14:13:15 at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:610) 14:13:15 at hudson.maven.Maven3Builder$JenkinsEventSpy.onEvent(Maven3Builder.java:306) 14:13:15 at org.apache.maven.eventspy.internal.EventSpyDispatcher.onEvent(EventSpyDispatcher.java:108) 14:13:15 at org.apache.maven.eventspy.internal.EventSpyExecutionListener.mojoSucceeded(EventSpyExecutionListener.java:131) 14:13:15 at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87) 14:13:15 at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) 14:13:15 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:227) 14:13:15 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) 14:13:15 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) 14:13:15 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108) 14:13:15 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76) 14:13:15 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) 14:13:15 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116) 14:13:15 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361) 14:13:15 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) 14:13:15 at org.jvnet.hudson.maven3.launcher.Maven31Launcher.main(Maven31Launcher.java:132) 14:13:15 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 14:13:15 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 14:13:15 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 14:13:15 at java.lang.reflect.Method.invoke(Method.java:597) 14:13:15 at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330) 14:13:15 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238) 14:13:15 at jenkins.maven3.agent.Maven31Main.launch(Maven31Main.java:181) 14:13:15 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 14:13:15 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 14:13:15 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 14:13:15 at java.lang.reflect.Method.invoke(Method.java:597) 14:13:15 at hudson.maven.Maven3Builder.call(Maven3Builder.java:134) 14:13:15 at hudson.maven.Maven3Builder.call(Maven3Builder.java:69) 14:13:15 at hudson.remoting.UserRequest.perform(UserRequest.java:118) 14:13:15 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 14:13:15 at hudson.remoting.Request$2.run(Request.java:328) 14:13:15 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 14:13:15 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 14:13:15 at java.util.concurrent.FutureTask.run(FutureTask.java:138) 14:13:15 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) 14:13:15 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 14:13:15 at java.lang.Thread.run(Thread.java:662) 14:13:15 Caused by: java.lang.LinkageError: Failed to load com.google.common.collect.AbstractMapBasedMultimap 14:13:15 at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:326) 14:13:15 at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236) 14:13:15 at java.lang.ClassLoader.loadClass(Unknown Source) 14:13:15 at java.lang.ClassLoader.loadClass(Unknown Source) 14:13:15 at java.lang.Class.forName0(Native Method) 14:13:15 at java.lang.Class.forName(Unknown Source) 14:13:15 at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113) 14:13:15 at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readClassDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readClassDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readClassDesc(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject0(Unknown Source) 14:13:15 at java.io.ObjectInputStream.defaultReadFields(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readSerialData(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject0(Unknown Source) 14:13:15 at java.io.ObjectInputStream.defaultReadFields(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readSerialData(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject0(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readArray(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject0(Unknown Source) 14:13:15 at java.io.ObjectInputStream.defaultReadFields(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readSerialData(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject0(Unknown Source) 14:13:15 at java.io.ObjectInputStream.readObject(Unknown Source) 14:13:15 at hudson.remoting.UserRequest.deserialize(UserRequest.java:182) 14:13:15 at hudson.remoting.UserRequest.perform(UserRequest.java:98) 14:13:15 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 14:13:15 at hudson.remoting.Request$2.run(Request.java:328) 14:13:15 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 14:13:15 at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) 14:13:15 at java.util.concurrent.FutureTask.run(Unknown Source) 14:13:15 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 14:13:15 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 14:13:15 at java.lang.Thread.run(Unknown Source) 14:13:15 Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap 14:13:15 at java.lang.ClassLoader.defineClass1(Native Method) 14:13:15 at java.lang.ClassLoader.defineClass(Unknown Source) 14:13:15 at java.lang.ClassLoader.defineClass(Unknown Source) 14:13:15 at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322) 14:13:15 ... 39 more
I have noticed this issue and the same error trace with Jenkins, Maven 3.2.1, FindBugs Maven plugin 2.5.3 - do we know which release the fix is targeted for or what is the workaround to continue the work? Thanks and much appreciate it.
Workaround proposed in JENKINS-19096 seems to work - trigger mvn job from freestyle projects.
Ugh. OSGi / Shade plugin to the rescue?
Any idea when this may be fixed?
btiernay
In this case, bumping the Guava dependency in Jenkins from v11 to v14 seems to me much simpler than OSGI.
(If you want to launch a long debate on the dreadful OSGI, this issue is probably not the good place and the dev list may be better.)
Just rammed into this trying to get FindBugs working for our project. I see no further comment in about a month - is anyone actively looking into upgrading Guava?
I have updated Guava myself and FindBugs works fine again.
There was an update to Guava 15 in Oct 13
https://github.com/jenkinsci/jenkins/commit/d45d18ed4e43057c42c363fe306f3945113f8f80
However, it was reverted again:
https://github.com/jenkinsci/jenkins/commit/cfe4b82994f261fe7623becfd2c7505679284026
I'm running into this with both findbugs and checkstyle on a maven build.
How are other people working around this? Does the freestyle project workaround still allow for the publishing of checkstyle/findbugs results automatically?
I've had to disable the "Publish Checkstyle analysis results" and "Publish FindBugs analysis results" on the jobs that have this error.
Inexplicable, some jobs seem to have an error similar to JENKINS-19096 instead:
[WARNING] Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy: null
At the same point that other jobs error out with:
Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap
I've been unable to determine what causes them to do different things.
I had to do the same until this issue is resolved, which is very unfortunate. I think this is a pretty big issue if you ask me.
Tim said in the comments above that upgrading the Guava dependency / jar file works around the issue.
Can others confirm this?
I think Tim was referring to the guava jar in Jenkins itself, unless I misunderstood.
Won't that then be overwritten any time Jenkins is upgraded? We upgrade Jenkins quite frequently, so I'd rather avoid introducing the need to keep overwriting that file manually.
I just updated Jenkins to 1.579 and tried the workaround of a Freestyle job, without success. The Maven versions that show up for me are "default" and 3.2.1, and leaving it at default gives me the following error
[WAR build] $ mvn -f OmnisMaven/pom.xml FATAL: command execution failed java.io.IOException: Cannot run program "mvn" (in directory "/usr/local/jenkins/workspace/WAR build"): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) at hudson.Proc$LocalProc.<init>(Proc.java:244) at hudson.Proc$LocalProc.<init>(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:802) at hudson.Launcher$ProcStarter.start(Launcher.java:380) at hudson.Launcher$ProcStarter.join(Launcher.java:387) at hudson.tasks.Maven.perform(Maven.java:328) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) at hudson.model.Run.execute(Run.java:1745) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.<init>(UNIXProcess.java:135) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1021) ... 15 more
Which appears to me to mean there is no default mvn, or it's MIA after the upgrade.
I've fixed it myself and are currently running a custom build of Jenkins.
https://github.com/xGhOsTkiLLeRx/jenkins/commit/7dc2e6f61dec78ce0b9ee19ace00dd9db060e5f1
(Ignore the version change, interesting is the guava version part)
@Rob: you need to either install maven automatically or specify the correct path to the maven binary in the system settings.
@Uli Thanks, I got it working by downgrading Maven to 3.0.5 (same version that ships with NetBeans).
I removed the 3.2.1 Maven, and my build works again (at least on Jenkins 1.578)
Does the freestyle project workaround still allow for the publishing of checkstyle/findbugs results automatically?
No, you need to configure the relevant publisher in the project, but generally this is pretty simple.
We use maven 3.2.1 for our build, and my workaround to this issue was to set up a separate maven project downstream from my main build, focused solely on static analysis. That one uses maven 3.0.4, and runs the usual set of suspects (findbugs, pmd, checkstyle).
Just remember, for that one you need to also run the compile target, as findbugs needs the bytecode in order to do its analysis (so yeah, it's pretty redundant, but it works). When my static analysis requirements become more firm, I may set it so the analysis is the *upstream* project (meaning the app will not get to the package phase under maven 3.2.1 if it fails the static checks that run with maven 3.0.4), but that's something to tackle another day.
Results/graphs/reports are still published as you'd normally expect them to, as they take advantage of the findbugs, checkstyle, and static analysis Jenkins plugins.
I did not need to explicitly install maven 3.0.4 on my server. I let Jenkins do that for me in my project configuration. I set up my overall Jenkins config to have two different maven builds available (these are local to Jenkins), and specified the one I wanted in my individual projects. NOTE: These projects are both Maven projects. They are not freestyle projects. Nothing against freestyle, just wanted to point out that you can work your way around this problem either way.
Can this be fixed in https://wiki.jenkins-ci.org/display/JENKINS/Task+Scanner+Plugin ?
When switching off <hudson.plugins.tasks.TasksReporter plugin="tasks@4.40"> we no longer receive:
2014-09-17T13:26:10.115 [INFO] Building xxxxxx-jenkins-test-ejb 2014.3.1-15-SNAPSHOT 2014-09-17T13:26:10.117 [INFO] ------------------------------------------------------------------------ 2014-09-17T13:26:10.236 [INFO] 2014-09-17T13:26:10.236 [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ xxxxxx-jenkins-test-ejb --- [TASKS] Scanning folder 'D:\jenkins-TEST-Slave1\workspace\xxxxxx-jenkins-test\xxxxxx\xxxxxx-jenkins-test\xxxxxx-jenkins-test-ejb' for files matching the pattern '**/*.java, **/*.xml' - excludes: [TASKS] Found 9 files to scan for tasks Found 0 open tasks. 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 $Proxy4.execute(Unknown Source) at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:206) at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:325) at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:316) 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:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) 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:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) 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:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) 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$Sync.innerRun(FutureTask.java:315) at java.util.concurrent.FutureTask.run(FutureTask.java:150) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:898) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:920) at java.lang.Thread.run(Thread.java:736) 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) 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 jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) 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:745) 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) ... 39 more 2014-09-17T13:26:10.354 [INFO] 2014-09-17T13:26:10.354 [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ xxxxxx-jenkins-test-ejb ---
Any news on getting the version fixed officially so that these kinds of workarounds are necessary? Cheers,
Eugen.
Any news?
I'm not much into running custom builds of Jenkins, and I can't afford to spend time working on that if I can't justify it to my boss...
I was able make it work using a Freestyle project with Maven 3.2.1.
Jenkins 1.581
Maven Integration plugin 2.7.1
PMD plugin 3.39
Freestyle project != maven project.
Maven project provides deep integration that has such penalties.
Freestyle just executes real mvn binary.
I have encountered a similar problem in our environment, where we have a main jenkins server (called 'master' or 'build') and a slave (called 'build2').
We realise that the exception described above (Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap) is only thrown when the job runs on build2. build2 was replaced recently which made us compare the versions of maven installed. The conclusion was that master and build2 have different versions of maven: 3.0.4 and 3.0.5 respectively.
Not sure if coincidence or not, but the guava libraries under maven repo ($MAVEN_HOME/lib, where MAVEN_HOME=/ush/share/maven) for each build server had different versions:
- master:
build:/usr/share/java$ ls /usr/share/java/gua* /usr/share/java/guava.jar -> guava-r09.jar /usr/share/java/guava-r09.jar
- build2:
build2:/usr/share/java$ ls guava* guava.jar guava-15.0.jar -> guava.jar
and that was the reason why the job on build2 (checkstyle and pmd) throws an exception; build2 is a slave of master; In order to run a job on build2, a slave.jar is downloaded from master (https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds) but the maven repo used is the one on build2. That slave.jar expects that the guava library available in the maven repo to be r09 (like master). Because it is not, this exception is being thrown.
To fix this issue, I have copied the guava.jar from master to build2:
build2:/usr/share/java$ ls guava* guava.jar guava-r09.0.jar -> guava.jar
And now the job runs seamlessly for both master and build2 (without the need to create a freestyle job)!!
System info:
Jenkins 1.546
Maven Integration plugin 2.1
PMD plugin 3.37
checkstyle plugin 3.38
Static Analysis Utilities 1.65
FindBugs-jsr305
Hope this explanation helps.
Has there been any progress on this ticket? Can't the plugin simply shade the Guava dependency to not conflict with those exposed by Jenkins? I find it very frustrating that I can't simultaneously use FindBugs with Maven 3.2.1+ (which supports wildcard excludes, a key feature). Sorry to be so curt, but this is quite the blocker and I see little or no progress over the past year. Thanks in advance.
You can use Maven 3.x and Findbugs. Just don't use the broken Maven project type. Everything works with the freestyle project type.
Hi Ulli Hafner,
We have build a "template engine" around the Maven Project Type. Do you (or anybody else) know if the Maven Project Type are going to be supported with this again - or do we have to switch to the Freestyle project type to get Findbugs working again ?
Kind regards
Claus Nielsen
I don't think that it is worth fixing the current implementation. There are so many different class loading problems up to now. My plan is to enable the existing freestyle publisher in maven projects, too. (That is quite easy to achieve, the messy part is that there needs to be a migration path for existing maven projects...).
Does not work again:
- maven-3.2.5
- jenkins-1.618 running as standalone instance (debian installation)
- analysis-core 1.72
- task scanner 4.45
Maven Job
According to https://github.com/jenkinsci/jenkins/blame/master/pom.xml#L187 guava in the core is still 11.0.1.
Same here. Downgrade of the Maven Integration plugin from 2.12 to 2.10 fixed the problem.
We had similar issues with Jenkins 1.627/Apache Maven 3.3.3/Maven Integration plugin 2.12. The solution was to move the Maven Integration plugin back to 2.11 and all worked well.
Going back to maven plugin version 2.10 did the trick for us as well.
Same here, using Jenkins v1.629, downgrading to Mvn integration plugin 2.9 solved it.
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/maven/AbstractMavenProcessFactory.java
http://jenkins-ci.org/commit/maven-plugin/51b204897c19c9be3b03a0a80482d096ae1db3e3
Log:
Revert "[FIX JENKINS-26947] forcibly terminate Maven remoting channel when upstream channel get closed"
[FIXED JENKINS-22252] Caused a regression.
This reverts commit 47b28737803ef90bc7e6518e159df28471988bae.
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/maven/AbstractMavenProcessFactory.java
http://jenkins-ci.org/commit/maven-plugin/e85502ac9b4e05f8ff8a476c795057a770cdc97f
Log:
Merge pull request #52 from jglick/IllegalAccessError-JENKINS-22252
JENKINS-22252 Revert JENKINS-26947 fix
Compare: https://github.com/jenkinsci/maven-plugin/compare/22dcb14846e2...e85502ac9b4e
Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/plugins/MavenPluginTest.java
http://jenkins-ci.org/commit/acceptance-test-harness/cf34c9c34f85d43f13d7b854274318cfba61793a
Log:
JENKINS-22252 Reproduced problem in test.
Code changed in jenkins
User: Jesse Glick
Path:
src/test/java/plugins/MavenPluginTest.java
http://jenkins-ci.org/commit/acceptance-test-harness/aac742512f570755f3e86df107214b4b1502e10f
Log:
Merge pull request #41 from jglick/IllegalAccessError-JENKINS-22252
JENKINS-22252 Reproduced problem in test
Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/23d6da28e7d7...aac742512f57
@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.