On Thu, Feb 2, 2017 at 11:25 AM, Andreas Mandel
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 rem
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
On Thu, Feb 2, 2017 at 5:09 AM, Andreas Mandel 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
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
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 t
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 ki
