-
Improvement
-
Resolution: Fixed
-
Major
-
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.
- is related to
-
JENKINS-17373 Unconditionally display tool installation selector
-
- Open
-
-
JENKINS-10191 JDK selection is hidden even when a JDK is configured
-
- Open
-
-
JENKINS-12550 System default JDK wrongly used if JDK is created first
-
- Resolved
-
-
JENKINS-31217 No JDK named ‘null’ found in Jenkins 1.635
-
- Resolved
-
[JENKINS-755] Default JDK meaning in project options is confusing.
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...
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.
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.
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.
That is interesting. I still have the default option, but only for freestyle projects and not m2 projects.
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.
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
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?
- 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.
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.
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.
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.
Following thread relates to this issue:
https://groups.google.com/forum/#!topic/jenkinsci-users/p7mUidJfNYQ
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>"
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.
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.
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.
"(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.
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.
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.
The default JDK is not determined by $PATH, but by the running JRE. (AFAIK)
jglick: 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.
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: 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.
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
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
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
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)'.
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.