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

Jenkins 1.518 causes Java 5 Maven builds to fail

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • maven-plugin
    • Ubuntu Linux 12.04 LTS
      Slave.jar running under Java 7
      Project: Maven 3.0.4, JDK 5 Update 22

      After the upgrade from Jenkins 1.515 to Jenkins 1.518 one of our Maven projects failed due to a ClassFormatException:

      23:13:30 [JENKINS] Archiving site from /export/build/jenkins-slave/workspace/xxx-nightly-trunk/target/site to /export/build/jenkins/jobs/xxx-nightly-trunk/site
      23:13:37 java.lang.reflect.InvocationTargetException
      23:13:37 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      23:13:37 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      23:13:37 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      23:13:37 	at java.lang.reflect.Method.invoke(Method.java:592)
      23:13:37 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
      23:13:37 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
      23:13:37 	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
      23:13:37 	at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
      23:13:37 	at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
      23:13:37 	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      23:13:37 	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      23:13:37 	at hudson.remoting.Request$2.run(Request.java:326)
      23:13:37 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      23:13:37 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
      23:13:37 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
      23:13:37 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
      23:13:37 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
      23:13:37 	at java.lang.Thread.run(Thread.java:595)
      23:13:37 Caused by: java.lang.ClassFormatError: Failed to load jnr.ffi.mapper.FunctionMapper
      23:13:37 	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193)
      23:13:37 	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144)
      23:13:37 	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      23:13:37 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
      23:13:37 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
      23:13:37 	at hudson.os.PosixAPI.jnr(PosixAPI.java:30)
      23:13:37 	at hudson.util.IOUtils.mode(IOUtils.java:125)
      23:13:37 	at hudson.util.io.TarArchiver.visit(TarArchiver.java:102)
      23:13:37 	at hudson.util.DirScanner$Glob.scan(DirScanner.java:133)
      23:13:37 	at hudson.FilePath.writeToTar(FilePath.java:1979)
      23:13:37 	at hudson.FilePath.copyRecursiveTo(FilePath.java:1905)
      23:13:37 	at hudson.FilePath.copyRecursiveTo(FilePath.java:1832)
      23:13:37 	at hudson.maven.reporters.MavenSiteArchiver.postExecute(MavenSiteArchiver.java:82)
      23:13:37 	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:453)
      23:13:37 	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:435)
      23:13:37 	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87)
      23:13:37 	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:228)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
      23:13:37 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
      23:13:37 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
      23:13:37 	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
      23:13:37 	... 18 more
      23:13:37 Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file
      23:13:37 	at java.lang.ClassLoader.defineClass1(Native Method)
      23:13:37 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
      23:13:37 	at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
      23:13:37 	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:191)
      23:13:37 	... 44 more
      23:13:37 channel stopped
      23:13:38 ERROR: Failed to parse POMs
      

      The issue can be found in the call stack:
      The Jenkins slave calls the Maven launcher and and the Maven launcher does a callback into the Jenkins code to perform some IO operations. For those operations, the jnr-ffi library is used and this has been compiled on the 8th of June under OpenJDK 6 and under Oracle JDK 7:
      https://travis-ci.org/jnr/jnr-ffi
      The pom.xml of the library has no compiler plugin configuration and thus creates code for whatever JDK it runs on (Java 6 class version 50) and I assume that this new version of the library has been pulled in between 1.516 and 1.518 of Jenkins.

      That means this new version of the jnr-ffi library drops Java 5 support for certain Maven builds.

          [JENKINS-18403] Jenkins 1.518 causes Java 5 Maven builds to fail

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/remoting/Channel.java
          src/main/java/hudson/remoting/RemoteClassLoader.java
          http://jenkins-ci.org/commit/remoting/09f20f11498cade0043e4400b91dec4b3531b0ab
          Log:
          JENKINS-18403 More reliable way of enforcing maximum bytecode version on a remoting channel.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/remoting/Channel.java src/main/java/hudson/remoting/RemoteClassLoader.java http://jenkins-ci.org/commit/remoting/09f20f11498cade0043e4400b91dec4b3531b0ab Log: JENKINS-18403 More reliable way of enforcing maximum bytecode version on a remoting channel.

          Bernat Bautista added a comment - - edited

          Helo,

          After upgrading from 1.551 to 1.582, the same happens again:

            • With 1.551:

          Parsing POMs
          [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/jdk1.5.0_22/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.33.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 50617
          <===[JENKINS REMOTING CAPACITY]===>channel started
          ERROR: JENKINS-18403 JDK 5 not supported to run Maven; retrying with slave Java and setting compile/test properties to point to /usr/lib/jvm/jdk1.5.0_22
          [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.33.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 60808

            • With 1.582

          Parsing POMs
          [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/jdk1.5.0_22/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.45.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 60914
          Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
          at java.lang.ClassLoader.defineClass1(Native Method)
          at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
          at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
          at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
          at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
          at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
          at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
          at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
          at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
          at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:135)
          at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:64)
          ERROR: Failed to parse POMs

          Bernat Bautista added a comment - - edited Helo, After upgrading from 1.551 to 1.582, the same happens again: With 1.551: Parsing POMs [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/jdk1.5.0_22/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.33.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 50617 <=== [JENKINS REMOTING CAPACITY] ===>channel started ERROR: JENKINS-18403 JDK 5 not supported to run Maven; retrying with slave Java and setting compile/test properties to point to /usr/lib/jvm/jdk1.5.0_22 [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.33.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 60808 With 1.582 Parsing POMs [AGD-ActuarialEngine_9010_Nightly] $ /usr/lib/jvm/jdk1.5.0_22/bin/java -Xmx512M -XX:MaxPermSize=512M -cp /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/data/jenkins/tools/maven3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /data/jenkins/tools/maven3.0.4 /var/lib/tomcat6/webapps/jenkins/WEB-INF/lib/remoting-2.45.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /data/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 60914 Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386) at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:135) at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:64) ERROR: Failed to parse POMs

          Jesse Glick added a comment -

          bernatb as of 1.533 the Maven plugin is not part of core, so the core version is (probably) not relevant, only the Maven plugin version.

          Jesse Glick added a comment - bernatb as of 1.533 the Maven plugin is not part of core, so the core version is (probably) not relevant, only the Maven plugin version.

          I rolled back the plugin to 2.3 (the oldest version I found) but with no luck. The issue definitely exists again with core 1.565.3 and Maven Integration plugin 2.7.

          It was working with core 1.563.jar and Maven Integration plugin 2.3.

          • Test with 1.563 and plugin 2.7 also works fine.
          • Test with 1.565 and plugin 2.7 also works fine.
          • Test with 1.565.2 and plugin 2.7 also works fine.
          • Test with 1.565.3 and plugin 2.7 fails.
          • Test with 1.574 and plugin 2.7 works fine.
          • Test with 1.575 and plugin 2.7 works fine.
            I can not test bejond because I'm blocked by JENKINS-25144?

          -> The regression occurred between 1.565.2 and 1.565.3 and after 1.575.

          Andreas Mandel added a comment - I rolled back the plugin to 2.3 (the oldest version I found) but with no luck. The issue definitely exists again with core 1.565.3 and Maven Integration plugin 2.7. It was working with core 1.563.jar and Maven Integration plugin 2.3. Test with 1.563 and plugin 2.7 also works fine. Test with 1.565 and plugin 2.7 also works fine. Test with 1.565.2 and plugin 2.7 also works fine. Test with 1.565.3 and plugin 2.7 fails. Test with 1.574 and plugin 2.7 works fine. Test with 1.575 and plugin 2.7 works fine. I can not test bejond because I'm blocked by JENKINS-25144 ? -> The regression occurred between 1.565.2 and 1.565.3 and after 1.575.

          Jesse Glick added a comment -

          andreasmandel thank you for digging deeper. Would you be so kind as to file a new bug report blocking this one (use Link field in JIRA) with a summary of what you found, namely that this appears to be a regression in 1.565.3?

          Jesse Glick added a comment - andreasmandel thank you for digging deeper. Would you be so kind as to file a new bug report blocking this one (use Link field in JIRA) with a summary of what you found, namely that this appears to be a regression in 1.565.3?

          jglick Sure, I've created JENKINS-25325, for me that blocks a whole bunch of build jobs with no real way to work around, thus the severity.

          Andreas Mandel added a comment - jglick Sure, I've created JENKINS-25325 , for me that blocks a whole bunch of build jobs with no real way to work around, thus the severity.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/maven/AbstractMavenProcessFactory.java
          http://jenkins-ci.org/commit/maven-plugin/0913aa1f42f004786ea9b34b8cdfdbd9aa8dc4d6
          Log:
          [FIXED JENKINS-25272] Extend JENKINS-18403 workaround for newer remoting.jar built with -target 6.
          Also handle a SocketException in Channels.forProcess, arising because Maven31Main tries to load remoting classes and fails.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/maven/AbstractMavenProcessFactory.java http://jenkins-ci.org/commit/maven-plugin/0913aa1f42f004786ea9b34b8cdfdbd9aa8dc4d6 Log: [FIXED JENKINS-25272] Extend JENKINS-18403 workaround for newer remoting.jar built with -target 6. Also handle a SocketException in Channels.forProcess, arising because Maven31Main tries to load remoting classes and fails.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/maven/AbstractMavenProcessFactory.java
          http://jenkins-ci.org/commit/maven-plugin/c88577a3d56b0968eacb118bd3adb7ea35914a19
          Log:
          Merge pull request #49 from jglick/remoting-class-version-JENKINS-25272

          JENKINS-25272 Extend JENKINS-18403 workaround for newer remoting.jar

          Compare: https://github.com/jenkinsci/maven-plugin/compare/02ca06095f8f...c88577a3d56b

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/maven/AbstractMavenProcessFactory.java http://jenkins-ci.org/commit/maven-plugin/c88577a3d56b0968eacb118bd3adb7ea35914a19 Log: Merge pull request #49 from jglick/remoting-class-version- JENKINS-25272 JENKINS-25272 Extend JENKINS-18403 workaround for newer remoting.jar Compare: https://github.com/jenkinsci/maven-plugin/compare/02ca06095f8f...c88577a3d56b

          The latest fix works for me in 1.625.1, great!

          Nevertheless the javadocExecutable variable does not seem to get set, therefor the javadoc of the 'newer' JDK is used instead. Since the strict parser rules with the newer javadoc versions this likely leads to build errors. jglick shall I open a new ticket for this?

          As a workaround, setting:

          <properties>
              ...
              <javadocExecutable>${JAVA_HOME}/bin/javadoc</javadocExecutable>
          </properties>
          

          in the pom helps.

          Andreas Mandel added a comment - The latest fix works for me in 1.625.1, great! Nevertheless the javadocExecutable variable does not seem to get set, therefor the javadoc of the 'newer' JDK is used instead. Since the strict parser rules with the newer javadoc versions this likely leads to build errors. jglick shall I open a new ticket for this? As a workaround, setting: <properties> ... <javadocExecutable> ${JAVA_HOME}/bin/javadoc </javadocExecutable> </properties> in the pom helps.

          Jesse Glick added a comment -

          andreasmandel yes this would be a follow-on RFE. (Of course I would recommend just fixing the errors that the newer and better tool detected!)

          Jesse Glick added a comment - andreasmandel yes this would be a follow-on RFE. (Of course I would recommend just fixing the errors that the newer and better tool detected!)

            jglick Jesse Glick
            mirumpf Michael Rumpf
            Votes:
            3 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: