|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Looks like I'm reviving this pretty old one but IMHO it's definitely an important one.
I agree with the reporter because I ran into several issues caused by the "default JDK" assumption:
I created a fresh Jenkins (1.573) installation and configured the current JDK 7 (Java SE DK 1.7.0_u65) in Jenkins. Since one cannot select the JDK to use in (e.g.) Maven jobs I was assuming Jenkins would take the 1.7.0_u65 JDK. I also provided a fresh SSH slave node and ran across the following issues. If Java is not installed on the node, Jenkins copies a pretty old 1.6.0_u45 JDK for execution on the node and also correctly provides the specified 1.7.0_65 JDK for the job's builds. Unfortunately the Sonar post build step which was configured to use the same JDK as the job ("Inherit From Job") tried to use plain "java" which was not present on the slave node machine; the job failed. Selecting the 1.7.0_u65 JDK in the Sonar step configuration fixed this.
In a second scenario I installed a JDK on the SSH slave node such that Jenkins would not use the way too old 1.6.0_u45 JDK. Again the job was "configured" (since only one JDK was configured for Jenkins one cannot select which one to use) to use the "default JDK". Unfortunately the "default JDK" on the slave node was 1.7.0_u55 and NOT the 1.7.0_u65 JDK as specified in Jenkins main configuration. And ON TOP OF that, one has to define a second JDK just to be able to configure the job to use the right one (which it does eventually). Also with an actual selection the Sonar step configuration using "Inherit From Job" does what it is supposed to do.
Long story short; TL;DR:
The "default JDK" assumption is error prone and highly misleading. On a side note: I'd also like to see Jenkins use a more up-to-date JRE than 1.6 on SSH slave nodes if they don't have Java installed.