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

Default JDK meaning in project options is confusing.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Platform: HP, OS: Windows XP
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            teilo James Nord created issue -
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Maybe it's better off if we just get rid of this "default" thing altogether.
            Does it really buy us anything?

            If there's only one JDK configured in Hudson, I suppose we shouldn't even
            display the JDK selection drop-down and just stick to that JDK.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Maybe it's better off if we just get rid of this "default" thing altogether. Does it really buy us anything? If there's only one JDK configured in Hudson, I suppose we shouldn't even display the JDK selection drop-down and just stick to that JDK.
            Hide
            teilo James Nord added a comment -

            Alternativly if you only have one that is the default, but if you have multiple
            then you can select which is the default.

            Then if you wish to upgrade and most of your jobs are using the default you can
            do it in just one place. (and let the projects that need a different jdk use it.)

            ALthough I guess you could do this already by calling a jdk install "latest" and
            just change the path to which jdk it uses...

            Show
            teilo James Nord added a comment - Alternativly if you only have one that is the default, but if you have multiple then you can select which is the default. Then if you wish to upgrade and most of your jobs are using the default you can do it in just one place. (and let the projects that need a different jdk use it.) ALthough I guess you could do this already by calling a jdk install "latest" and just change the path to which jdk it uses...
            Hide
            bimargulies bimargulies added a comment -

            This problem seems more severe to me.

            I added a second JDK, and selected one of them for my project, and the project
            is still running with the JRE as JAVA_HOME instead of the JDK. I need the JDK.

            Either that or the maven-antrun-plugin is playing a nasty prank on me.

            Show
            bimargulies bimargulies added a comment - This problem seems more severe to me. I added a second JDK, and selected one of them for my project, and the project is still running with the JRE as JAVA_HOME instead of the JDK. I need the JDK. Either that or the maven-antrun-plugin is playing a nasty prank on me.
            Hide
            drulli Ulli Hafner added a comment -

            The same should be done for the default maven version.

            I would expect that you can configure a list of tools in Hudson. For each tool, you have a default version (in the system configuration) that will be used if a job does not select a version in the job configuration. If it is easier to implement we can use the version at the top of the list (even though this is not so clear to the user). Another idea would be to have a 'Latest' list box entry, that would automatically use the latest available.

            Show
            drulli Ulli Hafner added a comment - The same should be done for the default maven version. I would expect that you can configure a list of tools in Hudson. For each tool, you have a default version (in the system configuration) that will be used if a job does not select a version in the job configuration. If it is easier to implement we can use the version at the top of the list (even though this is not so clear to the user). Another idea would be to have a 'Latest' list box entry, that would automatically use the latest available.
            Hide
            teilo James Nord added a comment -

            WIth 1.389 I no longer see the ability to choose the JDK / Maven version if only one is installed - so as originally reported this is probably fixed (or my test setup is lacking something?).

            However Drulli's comment is valid that you may want a default and have jobs be able to choose that whatever it maps to.

            Show
            teilo James Nord added a comment - WIth 1.389 I no longer see the ability to choose the JDK / Maven version if only one is installed - so as originally reported this is probably fixed (or my test setup is lacking something?). However Drulli's comment is valid that you may want a default and have jobs be able to choose that whatever it maps to.
            Hide
            drulli Ulli Hafner added a comment -

            That is interesting. I still have the default option, but only for freestyle projects and not m2 projects.

            Show
            drulli Ulli Hafner added a comment - That is interesting. I still have the default option, but only for freestyle projects and not m2 projects.
            ndeloof Nicolas De Loof made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-10191 [ JENKINS-10191 ]
            kutzi kutzi made changes -
            Summary Default JDK meening in project options is confusing. Default JDK meaning in project options is confusing.
            Hide
            docwhat Christian Höltje added a comment -

            It would be nice to break this into two options: Default and System.
            Default would the the highest one on the list.
            System would use the system jdk.

            Why anyone would use System when Jenkins can manage the JDKs for you, I have no clue.

            Show
            docwhat Christian Höltje added a comment - It would be nice to break this into two options: Default and System. Default would the the highest one on the list. System would use the system jdk. Why anyone would use System when Jenkins can manage the JDKs for you, I have no clue.
            Hide
            jd_randolph James Randolph added a comment -

            It'd be worth it to get rid of the "Default" altogether to prevent any confusion as to what the current default is. I believe having new jobs select a specific JDK by default is a completely different issue. I just migrated an old Hudson server and "Default" kind of bit me because it was not what I expected.

            Just my 2 cents

            Show
            jd_randolph James Randolph added a comment - It'd be worth it to get rid of the "Default" altogether to prevent any confusion as to what the current default is. I believe having new jobs select a specific JDK by default is a completely different issue. I just migrated an old Hudson server and "Default" kind of bit me because it was not what I expected. Just my 2 cents
            Hide
            croesus Croesus Kall added a comment -

            Also ran into this: Added a second JDK, and all of a sudden all of the jobs switched to the default "system" jdk, causing a whole bunch of builds to fail.

            This also seems like the behavior for maven, i.e. if more than one maven installation is set up, "default" points to the maven version on the system path?

            Show
            croesus Croesus Kall added a comment - Also ran into this: Added a second JDK, and all of a sudden all of the jobs switched to the default "system" jdk, causing a whole bunch of builds to fail. This also seems like the behavior for maven, i.e. if more than one maven installation is set up, "default" points to the maven version on the system path?
            Hide
            sstack S Stack added a comment -
            • JDK mismatch just caused an important deploy here to fail. Worse, some jobs don't even show the JDK drop-down in their configuration screen. This means we have to modify the job config.xml directly.
            • Completely agree "default" is misleading. Is "default" the 2nd JDK defined?
            • Please consider removing this ambiguity which can cause incidents at the worst possible moment. Thanks.
            Show
            sstack S Stack added a comment - JDK mismatch just caused an important deploy here to fail. Worse, some jobs don't even show the JDK drop-down in their configuration screen. This means we have to modify the job config.xml directly. Completely agree "default" is misleading. Is "default" the 2nd JDK defined? Please consider removing this ambiguity which can cause incidents at the worst possible moment. Thanks.
            Hide
            hardwickj James Hardwick added a comment -

            We REALLY need some way to select what we feel is the global default. Even if the default is just the top-most defined JDK in "Configure System". And all it takes is renaming the option within the job to make it less ambiguous.

            The other problem with this is that when using "Default" it doesn't set JAVA_HOME for any jobs which use it.

            Show
            hardwickj James Hardwick added a comment - We REALLY need some way to select what we feel is the global default. Even if the default is just the top-most defined JDK in "Configure System". And all it takes is renaming the option within the job to make it less ambiguous. The other problem with this is that when using "Default" it doesn't set JAVA_HOME for any jobs which use it.
            Hide
            tan_go238 Go Tanaka added a comment -

            I met the same issue when added a second JDK on Windows Server.

            In my case, I renamed the files, java.exe, javaw.exe, javaws.exe in Windows\System32, into java_.exe, javaw_.exe, javaws_.exe and finally Jenkins runs using JAVA_HOME's java with "Default".

            I guess installing a second JDK will update java.exe in Windows\System32 and "Default" setting won't use JAVA_HOME.

            Show
            tan_go238 Go Tanaka added a comment - I met the same issue when added a second JDK on Windows Server. In my case, I renamed the files, java.exe, javaw.exe, javaws.exe in Windows\System32, into java_.exe, javaw_.exe, javaws_.exe and finally Jenkins runs using JAVA_HOME's java with "Default". I guess installing a second JDK will update java.exe in Windows\System32 and "Default" setting won't use JAVA_HOME.
            Hide
            hdave Dave Vree added a comment - - edited

            To make matters worse, if you have configured just one JDK, you don't get the choice to select between "default" and that JDK. I think that "default" should be removed from the selections altogether. To make it clear, I think the JDK selection should always be present and it should always have a choice called "Host JDK" (or maybe "Host System JDK"). I would finally add that selecting the "Host System JDK" should come with a warning that upgrading the host will affect all the jobs.

            Show
            hdave Dave Vree added a comment - - edited To make matters worse, if you have configured just one JDK, you don't get the choice to select between "default" and that JDK. I think that "default" should be removed from the selections altogether. To make it clear, I think the JDK selection should always be present and it should always have a choice called "Host JDK" (or maybe "Host System JDK"). I would finally add that selecting the "Host System JDK" should come with a warning that upgrading the host will affect all the jobs.
            Hide
            farrukhnajmi Farrukh Najmi added a comment -
            Show
            farrukhnajmi Farrukh Najmi added a comment - Following thread relates to this issue: https://groups.google.com/forum/#!topic/jenkinsci-users/p7mUidJfNYQ
            Hide
            iplaman Idan Bidani added a comment -

            Do you think this bug can be more generic and relate to all Jenkins tools: JDK, ant, Maven, Grails etc.
            The "(Default)" option functionality is not clear enough.
            My suggested solutions are:
            1. Renaming it to something like "Find in PATH" or point out it's function in the help of the tools can help a lot.
            2. Remove it completely
            3. Allow the user to choose what is the default action does: "Find tool in PATH", "Use the first entry", "Use <tool_name>"

            Show
            iplaman Idan Bidani added a comment - Do you think this bug can be more generic and relate to all Jenkins tools: JDK, ant, Maven, Grails etc. The "(Default)" option functionality is not clear enough. My suggested solutions are: 1. Renaming it to something like "Find in PATH" or point out it's function in the help of the tools can help a lot. 2. Remove it completely 3. Allow the user to choose what is the default action does: "Find tool in PATH", "Use the first entry", "Use <tool_name>"
            Hide
            vlk Vladimir Kralik added a comment -

            I think, that the "Default" is good option, because I have a lot of projects with standard configuration and only several project with different JDK requirement.
            Depending on JDK installed on system is not a good idea, because on different systems ( slaves ) could be different JDK installed, so I could get different results.

            There should be "rule" which says : "The first one JDK in configuration is default."
            And would be nice to have possibility change order via drag-n-drop.

            Show
            vlk Vladimir Kralik added a comment - I think, that the "Default" is good option, because I have a lot of projects with standard configuration and only several project with different JDK requirement. Depending on JDK installed on system is not a good idea, because on different systems ( slaves ) could be different JDK installed, so I could get different results. There should be "rule" which says : "The first one JDK in configuration is default." And would be nice to have possibility change order via drag-n-drop.
            Hide
            greg Greg horvath added a comment -

            This all seems very silly to me. This ticket has been open for 6.5 years, and all about just providing a way to choose a default option? Come now. If I have multiple things installed, I don't want to have to explicitly specify which one I want for every job. Just give a way to select a default, or decide on a way to select a default via heuristic (i.e. first in the list, alphabetical, numerology, whatever) and tell us what it is. But just fix this, please, because it's unnecessarily confusing. And the ticket is 6.5 years old.

            Show
            greg Greg horvath added a comment - This all seems very silly to me. This ticket has been open for 6.5 years, and all about just providing a way to choose a default option? Come now. If I have multiple things installed, I don't want to have to explicitly specify which one I want for every job. Just give a way to select a default, or decide on a way to select a default via heuristic (i.e. first in the list, alphabetical, numerology, whatever) and tell us what it is. But just fix this, please, because it's unnecessarily confusing. And the ticket is 6.5 years old.
            ahorst Andreas Horst made changes -
            Link This issue is related to JENKINS-12550 [ JENKINS-12550 ]
            Hide
            ahorst Andreas Horst added a comment -

            I highly vote for fixing this one way or another since - as everybody in here already stated - the ambiguity can cause quite some trouble (see my comment on #10191.

            Show
            ahorst Andreas Horst added a comment - I highly vote for fixing this one way or another since - as everybody in here already stated - the ambiguity can cause quite some trouble (see my comment on #10191 .
            Hide
            danielbeck Daniel Beck added a comment -

            "(System)" or "(System Default)" seem to be appropriate alternative names for the '(Default)' JDK. While not resolving related issues, at least that would be less ambiguous.

            Show
            danielbeck Daniel Beck added a comment - "(System)" or "(System Default)" seem to be appropriate alternative names for the '(Default)' JDK. While not resolving related issues, at least that would be less ambiguous.
            ircbot Jenkins IRC Bot made changes -
            Component/s maven-plugin [ 16033 ]
            Component/s maven2 [ 15487 ]
            Hide
            jglick Jesse Glick added a comment -

            See also JENKINS-17373. I think it would be better for tool selectors generally to always show all available options, even when there is only one choice.

            The default JDK is a little tricky because this exists only when Jenkins master (or the relevant slave) is actually running on a JDK, not just a JRE.

            Show
            jglick Jesse Glick added a comment - See also JENKINS-17373 . I think it would be better for tool selectors generally to always show all available options, even when there is only one choice. The default JDK is a little tricky because this exists only when Jenkins master (or the relevant slave) is actually running on a JDK, not just a JRE.
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-17373 [ JENKINS-17373 ]
            Hide
            danielbeck Daniel Beck added a comment -

            It's no different that the 'default' of all the other tools, is it? (Except that generally JDK has a higher chance of actually being available on the PATH.)

            Agreed that tool installations should always be visible. Hiding is just confusing, as is the different job behavior between 0 (don't allow configuring, use System Default), 1 (don't allow configuring, use configured JDK), and 2 (allow configuring, default to system default) configured installations. This behavior breaks jobs just by adding a second JDK to the global config.

            Show
            danielbeck Daniel Beck added a comment - It's no different that the 'default' of all the other tools, is it? (Except that generally JDK has a higher chance of actually being available on the PATH.) Agreed that tool installations should always be visible. Hiding is just confusing, as is the different job behavior between 0 (don't allow configuring, use System Default), 1 (don't allow configuring, use configured JDK), and 2 (allow configuring, default to system default) configured installations. This behavior breaks jobs just by adding a second JDK to the global config.
            Hide
            jglick Jesse Glick added a comment -

            The default JDK is not determined by $PATH, but by the running JRE. (AFAIK)

            Show
            jglick Jesse Glick added a comment - The default JDK is not determined by $PATH , but by the running JRE. (AFAIK)
            Hide
            danielbeck Daniel Beck added a comment - - edited

            Jesse Glick: Doesn't look like it: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/JDK.java#L148

            And AbstractProject calls Jenkins.getInstance().getJDK(String) from getEnvironment(...) and if none is found by that name (e.g. "(Default)" or the various obsolete localized variants), null is returned and no JAVA_HOME set for the build, hoping for one defined by default.

            Show
            danielbeck Daniel Beck added a comment - - edited Jesse Glick : Doesn't look like it: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/JDK.java#L148 And AbstractProject calls Jenkins.getInstance().getJDK(String) from getEnvironment(...) and if none is found by that name (e.g. " (Default) " or the various obsolete localized variants), null is returned and no JAVA_HOME set for the build, hoping for one defined by default.
            Hide
            dubzerino 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.

            Show
            dubzerino 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.
            Hide
            dragomir 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?

            Show
            dragomir 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?
            Hide
            danielbeck Daniel Beck added a comment -

            Dragomir Nedyalkov: 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.

            Show
            danielbeck Daniel Beck added a comment - Dragomir Nedyalkov : 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.
            Hide
            vlk 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.

            Show
            vlk 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.
            Hide
            wilfredh Wilfred Hughes added a comment -

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

            Show
            wilfredh Wilfred Hughes added a comment - I've opened a pull request to improve the wording here: https://github.com/jenkinsci/jenkins/pull/1528
            Hide
            dogfood 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
            Show
            dogfood 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
            Show
            oleg_nenashev Oleg Nenashev added a comment - Fixed in https://github.com/jenkinsci/jenkins/pull/1528
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            mwebber Matthew Webber made changes -
            Link This issue is related to JENKINS-31217 [ JENKINS-31217 ]
            Hide
            mwebber 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

            Show
            mwebber 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
            jglick Jesse Glick made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            jglick Jesse Glick made changes -
            Assignee Wilfred Hughes [ wilfredh ]
            Hide
            scm_issue_link 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)'.

            Show
            scm_issue_link 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)'.
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 130828 ] JNJira + In-Review [ 186422 ]

              People

              • Assignee:
                wilfredh Wilfred Hughes
                Reporter:
                teilo James Nord
              • Votes:
                48 Vote for this issue
                Watchers:
                51 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: