-
Bug
-
Resolution: Unresolved
-
Minor
-
None
"default" JDK is the one present in user PATH - let's say JDK6
if I want to use an alternative JDK5, I declare it on system configuration
But I still can't edit my project configuration to select JDK and it still run with JDK6
I need to declare a 2nd JDK so that the select box appears and I can configure my JDK5 build.
I suggest to deprecate support for "Default" JDK, as this is confusing and dependent on host system configuration.
To ensure backward compatibility, jenkins could detect at startup jobs that don't have a <JDK> element in config and automatically create a "System" JDK in global configuration based on System.getProperty('java.home').
- is duplicated by
-
-
- Resolved
-
- is related to
-
JENKINS-755 Default JDK meaning in project options is confusing.
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-10191] JDK selection is hidden even when a JDK is configured
Andreas: Please provide relevant config.xml from the affected jobs at the relevant points in time (as that will contain the JDK configuration even if hidden from UI). Your second job's issue does not appear to be possible if one JDK is configured system-wide.
And ambiguity strikes again: 1.7.0_u55 was the OS wide JDK on the slave node while 1.7.0_u65 was the Jenkins "system-wide" configured JDK. Since the job did not specify anything related to a JDK (you cannot select a JDK in a Maven job unless Jenkins has more than one JDK installation) the job used the OS JDK (which IMHO is wrong). It should never fall back to the environment since nobody can guarantee even the existence of a JDK for arbitrary environments.
I'll come back with the configuration files in a minute (I'll have to remove the second JDK installation in order to reproduce the original behavior).
config.no.jdk.xml is a job configuration where only one JDK installation is known to Jenkins (hence no actual value). config.with.jdk.xml is a configuration of the same job but this time an actual JDK (one of two JDKs known to Jenkins) is selected.
These are excerpts from some build console outputs.
With config.no.jdk.xml:
Started by user Andreas Horst Building remotely on lab76 (maven java) in workspace /home/jenkins/workspace/Vire Updating https://sselab.de/lab9/private/svn/vire/trunk/vire at revision '2014-07-21T16:52:50.204 +0200' At revision 156 no change for https://sselab.de/lab9/private/svn/vire/trunk/vire since the previous build Parsing POMs maven31-agent.jar already up to date maven31-interceptor.jar already up to date maven3-interceptor-commons.jar already up to date [Vire] $ java -XX:MaxPermSize=512m -Djava.awt.headless=true -cp /home/jenkins/maven31-agent.jar:/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/boot/plexus-classworlds-2.5.1.jar:/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/conf/logging jenkins.maven3.agent.Maven31Main /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1 /home/jenkins/slave.jar /home/jenkins/maven31-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 60423 <===[JENKINS REMOTING CAPACITY]===>channel started Executing Maven: -B -f /home/jenkins/workspace/Vire/pom.xml -s /home/jenkins/.m2/settings.vire.xml clean install -e -X Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) Maven home: /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1 Java version: 1.7.0_55, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.13.0-32-generic", arch: "amd64", family: "unix" [INFO] Error stacktraces are turned on. [DEBUG] Reading global settings from /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/conf/settings.xml [DEBUG] Reading user settings from /home/jenkins/.m2/settings.vire.xml [INFO] Scanning for projects...
With config.with.jdk.xml:
Started by user Andreas Horst Building remotely on lab76 (maven java) in workspace /home/jenkins/workspace/Vire Updating https://sselab.de/lab9/private/svn/vire/trunk/vire at revision '2014-07-21T17:14:44.362 +0200' At revision 156 no change for https://sselab.de/lab9/private/svn/vire/trunk/vire since the previous build Parsing POMs maven31-agent.jar already up to date maven31-interceptor.jar already up to date maven3-interceptor-commons.jar already up to date [Vire] $ /home/jenkins/tools/hudson.model.JDK/Java_SE_Development_Kit_7u65/bin/java -XX:MaxPermSize=512m -Djava.awt.headless=true -cp /home/jenkins/maven31-agent.jar:/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/boot/plexus-classworlds-2.5.1.jar:/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/conf/logging jenkins.maven3.agent.Maven31Main /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1 /home/jenkins/slave.jar /home/jenkins/maven31-interceptor.jar /home/jenkins/maven3-interceptor-commons.jar 43246 <===[JENKINS REMOTING CAPACITY]===>channel started Executing Maven: -B -f /home/jenkins/workspace/Vire/pom.xml -s /home/jenkins/.m2/settings.vire.xml clean install -e -X Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) Maven home: /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1 Java version: 1.7.0_65, vendor: Oracle Corporation Java home: /home/jenkins/tools/hudson.model.JDK/Java_SE_Development_Kit_7u65/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.13.0-32-generic", arch: "amd64", family: "unix" [INFO] Error stacktraces are turned on. [DEBUG] Reading global settings from /home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.2.1/conf/settings.xml [DEBUG] Reading user settings from /home/jenkins/.m2/settings.vire.xml [INFO] Scanning for projects...
As you can see, the first build is IMHO run with the wrong JDK since the default JDK there is the OS JDK and NOT the single JDK known to Jenkins (which was 1.7.0_u65). Only after selecting the right JDK in the job configuration (which required adding a second JDK installation) the build was executed with the right JDK (second console output).
As a side note: I can no longer reproduce the Sonar issue since apparently the value of the <jdk> element in the job configuration differs between a fresh Jenkins installation with only one JDK installation and a Jenkins which had two JDK installations of which one was removed later on.
Just ran into this as well and a bit of googling led me here. However, my wants are slightly different: I'd also like an option to tell Jenkins to explicitly use the System provided JDK. Mainly because the Jenkins I currently maintain should use the same JDK/JRE we have in production and we maintain the JDK/JRE with puppet, outside of the Jenkins eco-system.
I do agree that the current way to work with JDK's in Jenkins is a bit confusing and it does not tie all plugins together (maven job with sonar's 'inherit from job' when the job's JDK is 'Default' is one such example).
Robert Dahlström
added a comment - - edited Just ran into this as well and a bit of googling led me here. However, my wants are slightly different: I'd also like an option to tell Jenkins to explicitly use the System provided JDK. Mainly because the Jenkins I currently maintain should use the same JDK/JRE we have in production and we maintain the JDK/JRE with puppet, outside of the Jenkins eco-system.
I do agree that the current way to work with JDK's in Jenkins is a bit confusing and it does not tie all plugins together (maven job with sonar's 'inherit from job' when the job's JDK is 'Default' is one such example). 
S
added a comment - I can confirm this is still present in v2.19.
I noticed sometime after 2.17 that all of my JDK tool installations were gone, and that the UI selection for the JDK for all maven jobs was no longer visible, but was still set in the config.xml.
S
added a comment - I can confirm this is still present in v2.19.
I noticed sometime after 2.17 that all of my JDK tool installations were gone, and that the UI selection for the JDK for all maven jobs was no longer visible, but was still set in the config.xml. of my JDK tool installations were gone, and that the UI selection for the JDK for all maven jobs was no longer visible
Moved to /configureTools
S
added a comment - Correct, however I am confirming that the JDK selection from a maven job is not visible even though it is specified in the job's configuration. That was a side-effect I noticed at the same time (may or may not be related).
S
added a comment - Correct, however I am confirming that the JDK selection from a maven job is not visible even though it is specified in the job's configuration. That was a side-effect I noticed at the same time (may or may not be related).
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.