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

Default JDK meaning in project options is confusing.

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • maven-plugin
    • None
    • Platform: HP, OS: Windows XP

      When the option for which JDK to use for native m2 builds is set to "default"
      and there is only one jdk configured in hudson the builds should use that jdk
      not the jdk/jre of the container.

      if there are more jdks' configured hudson should use the first one configured
      at the system level for default.

          [JENKINS-755] Default JDK meaning in project options is confusing.

          Al Murphy added a comment -

          This inordinately long-standing issue is deeply insidious. We're currently in the process of mopping up the carnage caused by having merely added Java 7 to a Jenkins instance which previously only knew of Java 6 – an action that should be additive, and benign.

          If this isn't going to be fixed any time soon, I would strongly recommend at least placing a giant disclaimer on the Jenkins Configuration page, detailing the peril of adding a second JDK. That would at least address the insidiousness, if not the bizarreness of the behaviour.

          Al Murphy added a comment - This inordinately long-standing issue is deeply insidious. We're currently in the process of mopping up the carnage caused by having merely added Java 7 to a Jenkins instance which previously only knew of Java 6 – an action that should be additive, and benign. If this isn't going to be fixed any time soon, I would strongly recommend at least placing a giant disclaimer on the Jenkins Configuration page, detailing the peril of adding a second JDK. That would at least address the insidiousness, if not the bizarreness of the behaviour.

          Not sure, in which direction the issue resolving is going to, but ...
          Imagine the scenario when you have environment with hundreds of already setup build jobs, running with the one and only (default in this case) JDK available for the CI server .
          Then comes a day you need to setup 2 new build jobs to run against the latest and greatest Oracle JDK.
          What practically happens – The latest and greatest JDK installed on the system and configured for the Jenkins, becomes the “Default” one for all available build jobs. And one needs to manually reconfigure hundreds of build jobs, and explicitly to tell them to use the former JDK….
          I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          Dragomir Nedyalkov added a comment - Not sure, in which direction the issue resolving is going to, but ... Imagine the scenario when you have environment with hundreds of already setup build jobs, running with the one and only (default in this case) JDK available for the CI server . Then comes a day you need to setup 2 new build jobs to run against the latest and greatest Oracle JDK. What practically happens – The latest and greatest JDK installed on the system and configured for the Jenkins, becomes the “Default” one for all available build jobs. And one needs to manually reconfigure hundreds of build jobs, and explicitly to tell them to use the former JDK…. I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          Daniel Beck added a comment -

          dragomir: That one is easy: Add a second explicit JDK (that no job will be using) and configure the two jobs to explicitly use the first explicit JDK.

          OTOH if you already had 1 configured JDK that was used by default by 100 jobs, and then add a second, and all jobs then back to System Default, that is a PITA. Either reconfigure a lot of jobs, or be stuck at 1 JDK forever.

          Daniel Beck added a comment - dragomir : That one is easy: Add a second explicit JDK (that no job will be using) and configure the two jobs to explicitly use the first explicit JDK. OTOH if you already had 1 configured JDK that was used by default by 100 jobs, and then add a second, and all jobs then back to System Default, that is a PITA. Either reconfigure a lot of jobs, or be stuck at 1 JDK forever.

          Dragomir said

          I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          By using Configuration Slicing Plugin there is possible to change JDK in a lot of jobs in simple way.

          Vladimir Kralik added a comment - Dragomir said I do not see any workaround to get out of this nasty situation easily. Or am I wrong? By using Configuration Slicing Plugin there is possible to change JDK in a lot of jobs in simple way.

          I've opened a pull request to improve the wording here: https://github.com/jenkinsci/jenkins/pull/1528

          Wilfred Hughes added a comment - I've opened a pull request to improve the wording here: https://github.com/jenkinsci/jenkins/pull/1528

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4340
          JENKINS-755 Describe the built-in JDK as '(System)'. (Revision ff021d3c374a067d622fdb078a4e391149df7d41)

          Result = SUCCESS
          whughes : ff021d3c374a067d622fdb078a4e391149df7d41
          Files :

          • core/src/main/java/hudson/model/JDK.java

          dogfood added a comment - Integrated in jenkins_main_trunk #4340 JENKINS-755 Describe the built-in JDK as '(System)'. (Revision ff021d3c374a067d622fdb078a4e391149df7d41) Result = SUCCESS whughes : ff021d3c374a067d622fdb078a4e391149df7d41 Files : core/src/main/java/hudson/model/JDK.java

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - Fixed in https://github.com/jenkinsci/jenkins/pull/1528

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0cc465e706f69b7ee0389749233ab2f33ca47eed
          Log:
          Noting fix of JENKINS-755 in https://github.com/jenkinsci/jenkins/pull/1528

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: changelog.html http://jenkins-ci.org/commit/jenkins/0cc465e706f69b7ee0389749233ab2f33ca47eed Log: Noting fix of JENKINS-755 in https://github.com/jenkinsci/jenkins/pull/1528

          The fix for this problem, which was released in Jenkins 1.635, appears to have caused a new bug JENKINS-31217

          Matthew Webber added a comment - The fix for this problem, which was released in Jenkins 1.635, appears to have caused a new bug JENKINS-31217

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/model/AbstractProject.java
          core/src/main/java/hudson/model/JDK.java
          core/src/main/java/jenkins/model/Jenkins.java
          core/src/test/java/jenkins/model/JDKNameTest.java
          http://jenkins-ci.org/commit/jenkins/730d6ecb2d29b25ef69f5cf49e097fb09dbfc3a6
          Log:
          Merge pull request #1528 from Wilfred/better_default_text

          JENKINS-755 Describe the built-in JDK as '(System)'.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/model/AbstractProject.java core/src/main/java/hudson/model/JDK.java core/src/main/java/jenkins/model/Jenkins.java core/src/test/java/jenkins/model/JDKNameTest.java http://jenkins-ci.org/commit/jenkins/730d6ecb2d29b25ef69f5cf49e097fb09dbfc3a6 Log: Merge pull request #1528 from Wilfred/better_default_text JENKINS-755 Describe the built-in JDK as '(System)'.

            wilfredh Wilfred Hughes
            teilo James Nord
            Votes:
            48 Vote for this issue
            Watchers:
            49 Start watching this issue

              Created:
              Updated:
              Resolved: