Hello Karl Heinz, thanks for picking this up.
I'm aware of toolchain - changing the poms is a blocker here there are many of these jobs where i have limited access to the development team. The settings.xml is distributed by puppet to the build nodes in my setup. I'm not sure what you mean that I would get the same issue on the local system. Maven 3.2 runs fine with Java 6 - which would cover most of the setups (bound to a Websphere 8.0), but this is not directly supported by Jenkins any more. Fixing the "switch" as it was originally implemented by Jesse Glick would also help. Not covering the last point (rely on the platform jdk) is not a blocker but not nice. My concern here is that if I update from Ubuntu 14.04 to 16.04 this will switch from java 7 to java 8 as the platform jdk, which will in fact affect the builds, leaving me with no control to adjust this from the Jenkins side. (triggering https://issues.jenkins-ci.org/browse/JENKINS-31036) Kind Regards, Andreas. Am Donnerstag, 2. Februar 2017 11:46:56 UTC+1 schrieb Karl Heinz Marbaise: > > > > On Thursday, February 2, 2017 at 11:09:48 AM UTC+1, Andreas Mandel wrote: >> >> Hello list, >> >> I try to get a fix for https://issues.jenkins-ci.org/browse/JENKINS-40990 >> (the new remoting in jenkins 2.32.1 causes maven builds with older jdk to >> fail). >> >> The mechanism to switch the jdk used to run maven to the platform jdk if >> a "UnsupportedClassVersionError" is caught does not kick in because this >> exception is not carried as cause any more and thus this situation is not >> detected. (affected class hudson.maven.AbstractMavenProcessFactory >> 298ff). >> >> My main requirements are: >> >> - must be able to run jdk 5 & 6 builds without a change in the >> projects pom >> - should not need to add hard coded path pointing to the jenkins >> auto-installed jdks anywhere >> - should not rely on the platform jdk to be the one to use >> >> >> > The correct way to handle this in Maven is to use toolchain... > > This will decouple the JDK which is used to run Maven itself and the one > which is used to compile the code and run the tests... > > But you need to change the pom file otherwise it will not work...and your > toolchains.xml file in Jenkins via the config file provider plugin which I > hope you already use for settings.xml file. > > Furthermore you need to do this cause on a local system you will get the > same problem running Maven 3 with JDK 7 but your code needs to have JDK > 7 or JDK 8 etc. > > https://maven.apache.org/guides/mini/guide-using-toolchains.html > > But it is not possible to handle your third point not to rely on the > platform JDK to be the one to use...and i don't see a real solution for > this nor I understand your concerns about that... > > > Another point to prevent using the "evil" Maven Job Type in Jenkins... > > > Kind regards > > Karl Heinz Marbaise > > > >> I think about a new option for the maven builds to allow to set the >> maven.compiler.executable and related variables based on a independent >> jdk selection. So one could choose to run maven with "jdk1.8.0" but to >> point the maven compiler etc. to "jdk1.5.0". The disadvantage of this is >> that the job configuration needs to be updated for every affected job, but >> we would gain control over the fallback jdk that is used. >> >> With the resent security fixes and the upcoming switch to java8 only this >> becomes critical to me since it blocks me from updating to the latest >> jenkins. >> >> Thoughts? >> >> >> Kind Regards, >> Andreas. >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a16e3696-34e9-4f42-9613-ce1578c1c8a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
