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

          Georg Sash added a comment -

          Guys, it is a constantly reoccurring issue that non-Java5 compatible class files get leaked into the Jenkins distribution. Is it so hard to add a test case that explicitly checks if Java5 support is still intact??

          Georg Sash added a comment - Guys, it is a constantly reoccurring issue that non-Java5 compatible class files get leaked into the Jenkins distribution. Is it so hard to add a test case that explicitly checks if Java5 support is still intact??

          Michael Rumpf added a comment -

          Our current workaround is to set the Maven compiler via command line:
          -Dmaven.compiler.executable=<JDK5-javac>

          Michael Rumpf added a comment - Our current workaround is to set the Maven compiler via command line: -Dmaven.compiler.executable=<JDK5-javac>

          Jesse Glick added a comment -

          The use of a 1.6-based copy of JNR here is almost irrelevant since https://github.com/jenkinsci/jenkins/commit/3431a7cba4a8c73d975ae7db69892a2eb473b5d0 in 1.520 means that all Jenkins code requires Java 6+ to run.

          Jesse Glick added a comment - The use of a 1.6-based copy of JNR here is almost irrelevant since https://github.com/jenkinsci/jenkins/commit/3431a7cba4a8c73d975ae7db69892a2eb473b5d0 in 1.520 means that all Jenkins code requires Java 6+ to run.

          Jesse Glick added a comment -
          diff --git a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          index bad99b0..cdabd33 100644
          --- a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          +++ b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          @@ -105,6 +105,8 @@ public final class ProcessCache {
                       this.parent = parent;
                       this.mavenOpts = mavenOpts;
                       this.channel = np.channel;
          +            short JDK5 = 5;
          +            channel.setMaximumBytecodeLevel(JDK5);
                       this.proc = np.proc;
                       this.installation = installation;
                       this.jdk = jdk;
          diff --git a/pom.xml b/pom.xml
          index 4c2ed2e..023fe37 100644
          --- a/pom.xml
          +++ b/pom.xml
          @@ -175,7 +175,7 @@ THE SOFTWARE.
                 <dependency>
                   <groupId>org.jenkins-ci.main</groupId>
                   <artifactId>remoting</artifactId>
          -        <version>2.28</version>
          +        <version>2.29-SNAPSHOT</version>
                 </dependency>
           
                 <dependency>
          

          shows how to reproduce the problem without even having JDK 5.

          Jesse Glick added a comment - diff --git a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java index bad99b0..cdabd33 100644 --- a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java +++ b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java @@ -105,6 +105,8 @@ public final class ProcessCache { this.parent = parent; this.mavenOpts = mavenOpts; this.channel = np.channel; + short JDK5 = 5; + channel.setMaximumBytecodeLevel(JDK5); this.proc = np.proc; this.installation = installation; this.jdk = jdk; diff --git a/pom.xml b/pom.xml index 4c2ed2e..023fe37 100644 --- a/pom.xml +++ b/pom.xml @@ -175,7 +175,7 @@ THE SOFTWARE. <dependency> <groupId>org.jenkins-ci.main</groupId> <artifactId>remoting</artifactId> - <version>2.28</version> + <version>2.29-SNAPSHOT</version> </dependency> <dependency> shows how to reproduce the problem without even having JDK 5.

          As of 1.520, core has moved on to Java6, so currently this is expected.

          To quote the changelog, "Core started relying on Java 1.6 as per the agreement in the dev list. If you have a serious objection against it, please let us know before we really start relying on 1.6 features."

          Kohsuke Kawaguchi added a comment - As of 1.520, core has moved on to Java6, so currently this is expected. To quote the changelog, "Core started relying on Java 1.6 as per the agreement in the dev list. If you have a serious objection against it, please let us know before we really start relying on 1.6 features."

          Jesse Glick added a comment -

          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)

          Not true; the JNR POM specifies <maven.compiler.target>1.6</maven.compiler.target> as of 1.0.0.

          (The Maven compiler plugin always uses a deterministic source/target level, regardless of the JDK used to run Maven. If unspecified, it currently defaults to JDK 5.)

          Jesse Glick added a comment - 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) Not true; the JNR POM specifies <maven.compiler.target>1.6</maven.compiler.target> as of 1.0.0. (The Maven compiler plugin always uses a deterministic source/target level, regardless of the JDK used to run Maven. If unspecified, it currently defaults to JDK 5.)

          Jesse Glick added a comment -

          While there is no current plan to fix this in the sense of restoring the ability to run Maven on JDK 5, I will investigate making the plugin behave more gracefully when JDK 5 is selected for the project.

          Jesse Glick added a comment - While there is no current plan to fix this in the sense of restoring the ability to run Maven on JDK 5, I will investigate making the plugin behave more gracefully when JDK 5 is selected for the project.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          http://jenkins-ci.org/commit/jenkins/db921dba15831aacc1043824f1a741564060ec94
          Log:
          JENKINS-18403 Commented-out bytecode level restriction for Maven process.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: maven-plugin/src/main/java/hudson/maven/ProcessCache.java http://jenkins-ci.org/commit/jenkins/db921dba15831aacc1043824f1a741564060ec94 Log: JENKINS-18403 Commented-out bytecode level restriction for Maven process.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          maven-plugin/src/main/java/hudson/maven/AbstractMavenProcessFactory.java
          http://jenkins-ci.org/commit/jenkins/288b8d0b01f92072d0b86efb898c011f31a7fc30
          Log:
          [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5.
          If so, retry with (6+) slave JVM, setting maven-

          {compiler,surefire}

          -plugin properties to point to original.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html maven-plugin/src/main/java/hudson/maven/AbstractMavenProcessFactory.java http://jenkins-ci.org/commit/jenkins/288b8d0b01f92072d0b86efb898c011f31a7fc30 Log: [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5. If so, retry with (6+) slave JVM, setting maven- {compiler,surefire} -plugin properties to point to original.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2726
          JENKINS-18403 Commented-out bytecode level restriction for Maven process. (Revision db921dba15831aacc1043824f1a741564060ec94)
          [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5. (Revision 288b8d0b01f92072d0b86efb898c011f31a7fc30)

          Result = UNSTABLE
          Jesse Glick : db921dba15831aacc1043824f1a741564060ec94
          Files :

          • maven-plugin/src/main/java/hudson/maven/ProcessCache.java

          Jesse Glick : 288b8d0b01f92072d0b86efb898c011f31a7fc30
          Files :

          • maven-plugin/src/main/java/hudson/maven/AbstractMavenProcessFactory.java
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #2726 JENKINS-18403 Commented-out bytecode level restriction for Maven process. (Revision db921dba15831aacc1043824f1a741564060ec94) [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5. (Revision 288b8d0b01f92072d0b86efb898c011f31a7fc30) Result = UNSTABLE Jesse Glick : db921dba15831aacc1043824f1a741564060ec94 Files : maven-plugin/src/main/java/hudson/maven/ProcessCache.java Jesse Glick : 288b8d0b01f92072d0b86efb898c011f31a7fc30 Files : maven-plugin/src/main/java/hudson/maven/AbstractMavenProcessFactory.java changelog.html

          Hello,
          We have several Jenkins jobs still using Java 5 (1.5.0 update 22) and even this bug should be fixed, we have still problem with running those jobs.
          We use the latest Jenkins 1.528 and if we run job based on JDK 1.5, during maven build we get info, that JDK 5 is not supported and that will be used instead of this JDK 1.6 but properties for compile/test will be pointing to JDK 1.5. But even maven build should use for compile/test JDK 1.5 properties, still is using JDK 1.6 !!! E.g. we get errors that some our classes did not implement Java API which was OK for JDK 1.5 but now is attempting to use API from Java 1.6 (which is bad).
          We use Maven 2.2.1 with JDK 1.5 on Jenkins 1.528 which runs on Oracle JDK 1.6 patch 43, Centos 6. And at our pom for failing job we have defined section like this:

          <plugin>
          	<groupId>org.apache.maven.plugins</groupId>
          	<artifactId>maven-compiler-plugin</artifactId>
          	<version>2.0.2</version>
          	<configuration>
          		<source>1.5</source>
          		<target>1.5</target>
          		<encoding>UTF-8</encoding>
          		<optimize>true</optimize>
          	</configuration>
          </plugin>
          

          Best regards,
          Pavel Cervenka

          Pavel Cervenka added a comment - Hello, We have several Jenkins jobs still using Java 5 (1.5.0 update 22) and even this bug should be fixed, we have still problem with running those jobs. We use the latest Jenkins 1.528 and if we run job based on JDK 1.5, during maven build we get info, that JDK 5 is not supported and that will be used instead of this JDK 1.6 but properties for compile/test will be pointing to JDK 1.5. But even maven build should use for compile/test JDK 1.5 properties, still is using JDK 1.6 !!! E.g. we get errors that some our classes did not implement Java API which was OK for JDK 1.5 but now is attempting to use API from Java 1.6 (which is bad). We use Maven 2.2.1 with JDK 1.5 on Jenkins 1.528 which runs on Oracle JDK 1.6 patch 43, Centos 6. And at our pom for failing job we have defined section like this: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> <encoding>UTF-8</encoding> <optimize>true</optimize> </configuration> </plugin> Best regards, Pavel Cervenka

          Jesse Glick added a comment -

          @cervenkap: so the fix is working to the extent that the Maven process is switched to a usable Java 6 JRE, but the attempt to configure it for JDK 5 development is not working. Please do some investigation and file a separate JIRA report “blocking” this one:

          1. Run Maven with -X and confirm that maven.compiler.fork=true and maven.compiler.executable=…/jdk5/bin/javac, and that the effective mojo configuration for compiler:compile shows fork and executable parameters correctly set, and check the logged command line which runs javac which should be using the JDK 5 version. (Can also check Surefire configuration: jvm should be …/jdk5/bin/java.)

          2. Check a current version of the Compiler plugin (2.0.2 is quite old), as well as checking Maven 3.x rather than 2.2.1, to see if these versions are triggering your issue.

          3. If running the build on the master, try on a slave, or vice-versa.

          (If your build which worked on JDK 5 is failing on JDK 6, I assume this means you are implementing one of the JDBC interfaces to which methods were added, or something along those lines, since normally JDK upgrades are compatible for compilation.)

          A pull request would be great, though with a clear diagnosis of what is going amiss in your environment a fix is probably easy to write.

          (BTW: <optimize>true</optimize> is essentially useless for modern JDKs.)

          Jesse Glick added a comment - @cervenkap: so the fix is working to the extent that the Maven process is switched to a usable Java 6 JRE, but the attempt to configure it for JDK 5 development is not working. Please do some investigation and file a separate JIRA report “blocking” this one: 1. Run Maven with -X and confirm that maven.compiler.fork=true and maven.compiler.executable=…/jdk5/bin/javac , and that the effective mojo configuration for compiler:compile shows fork and executable parameters correctly set, and check the logged command line which runs javac which should be using the JDK 5 version. (Can also check Surefire configuration: jvm should be …/jdk5/bin/java .) 2. Check a current version of the Compiler plugin (2.0.2 is quite old), as well as checking Maven 3.x rather than 2.2.1, to see if these versions are triggering your issue. 3. If running the build on the master, try on a slave, or vice-versa. (If your build which worked on JDK 5 is failing on JDK 6, I assume this means you are implementing one of the JDBC interfaces to which methods were added, or something along those lines, since normally JDK upgrades are compatible for compilation.) A pull request would be great, though with a clear diagnosis of what is going amiss in your environment a fix is probably easy to write. (BTW: <optimize>true</optimize> is essentially useless for modern JDKs.)

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/maven/ProcessCache.java
          http://jenkins-ci.org/commit/maven-plugin/e93877c5c479688dc78d7987fe1b7965b7877195
          Log:
          JENKINS-18403 Commented-out bytecode level restriction for Maven process.
          Originally-Committed-As: db921dba15831aacc1043824f1a741564060ec94

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/maven/ProcessCache.java http://jenkins-ci.org/commit/maven-plugin/e93877c5c479688dc78d7987fe1b7965b7877195 Log: JENKINS-18403 Commented-out bytecode level restriction for Maven process. Originally-Committed-As: db921dba15831aacc1043824f1a741564060ec94

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/maven/AbstractMavenProcessFactory.java
          http://jenkins-ci.org/commit/maven-plugin/9bd5bae03184777cd9280b8bced78793f39699b1
          Log:
          [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5.
          If so, retry with (6+) slave JVM, setting maven-

          {compiler,surefire}

          -plugin properties to point to original.
          Originally-Committed-As: 288b8d0b01f92072d0b86efb898c011f31a7fc30

          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/9bd5bae03184777cd9280b8bced78793f39699b1 Log: [FIXED JENKINS-18403] Detect when an attempt is made to run Maven on JDK 5. If so, retry with (6+) slave JVM, setting maven- {compiler,surefire} -plugin properties to point to original. Originally-Committed-As: 288b8d0b01f92072d0b86efb898c011f31a7fc30

          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: