maven project plugin and aged JDK versions

[Andreas Mandel]

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

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.

[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

[Andreas Mandel]

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.

[Jesse Glick]

On Thu, Feb 2, 2017 at 5:09 AM, Andreas Mandel <andreas...@gmail.com> wrote:
> 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.

Well the simplest way forward is to fix that so we can use the
existing workaround for a while longer. Figure out where the initial
error is not thrown, where it is caught, how it is thrown up. I have
no particular advice beyond running a debugger and/or adding some
`println`s.

[Andreas Mandel]

Hi Jesse,

thanks for the feedback. I already had a short look into this. It must be related to the changed remoting, the exception appears in the log but is not carried as root cause of the caught IOException any more. I did not find a way to get the "cause" exception based on the references at hand. I also do not know if this changed behavior of remoting is by intention or the root cause of the issue.

Kind Regards,
Andreas.

[Jesse Glick]

On Thu, Feb 2, 2017 at 11:25 AM, Andreas Mandel
<andreas...@gmail.com> wrote:
> the exception appears in the log but is not
> carried as root cause of the caught IOException any more. I did not find a
> way to get the "cause" exception based on the references at hand. I also do
> not know if this changed behavior of remoting is by intention

Not that I know of. Possibly a Remoting bug.