Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-10191

JDK selection is hidden even when a JDK is configured

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • 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').

        1. config.no.jdk.xml
          4 kB
        2. config.with.jdk.xml
          4 kB

          [JENKINS-10191] JDK selection is hidden even when a JDK is configured

          Nicolas De Loof created issue -
          Nicolas De Loof made changes -
          Description Original: "default" JDK is the one present in user PATH - let's say JDK6
          if I want to use an alternative JDK5, I declare i on system configuration
          But I still can't edit my project configuration to select it
          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.

          To ensure backward compatibility, jenkins can detect at startup jobs that don't have a <JDK> element in config and automatically create a "System" JDK in global configuration based on 'java.home'.
          		New: "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').
          Nicolas De Loof made changes -
          Link New: This issue is related to JENKINS-755 [ JENKINS-755 ]

          Andreas Horst added a comment -

          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.

          Andreas Horst added a comment - 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.
          Andreas Horst made changes -
          Link New: This issue is related to JENKINS-12550 [ JENKINS-12550 ]

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Andreas Horst added a comment -

          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).

          Andreas Horst added a comment - 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).

          Andreas Horst added a comment -

          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.

          Andreas Horst added a comment - 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.
          Andreas Horst made changes -
          Attachment New: config.no.jdk.xml [ 26415 ]
          Attachment New: config.with.jdk.xml [ 26416 ]

          Andreas Horst added a comment -

          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).

          Andreas Horst added a comment - 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).

            Unassigned Unassigned
            ndeloof Nicolas De Loof
            Votes:
            11 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated: