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

Jenkins 1.518 causes Java 5 Maven builds to fail

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
    • Environment:
      Ubuntu Linux 12.04 LTS
      Slave.jar running under Java 7
      Project: Maven 3.0.4, JDK 5 Update 22
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            andreasmandel Andreas Mandel added a comment -

            Jesse Glick 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.

            Show
            andreasmandel Andreas Mandel added a comment - Jesse Glick 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            andreasmandel 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. Jesse Glick shall I open a new ticket for this?

            As a workaround, setting:

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

            in the pom helps.

            Show
            andreasmandel 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. Jesse Glick shall I open a new ticket for this? As a workaround, setting: <properties> ... <javadocExecutable> ${JAVA_HOME}/bin/javadoc </javadocExecutable> </properties> in the pom helps.
            Hide
            jglick Jesse Glick added a comment -

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

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: