-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Master:
OS: Windows Server with Jenkins 1.509.1
JDK: 1.6.0u45 (C:\Program Files\Java\jdk1.6.0_45)
Slave:
OS: CentOS 6.4
JDK: java-1.7.0-openjdk-devel-1.7.0.19-2.3.9.1 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64)
The JDK is configured globally using the Windows path (the master also runs jobs) and is overridden for the slave.Master: OS: Windows Server with Jenkins 1.509.1 JDK: 1.6.0u45 (C:\Program Files\Java\jdk1.6.0_45) Slave: OS: CentOS 6.4 JDK: java-1.7.0-openjdk-devel-1.7.0.19-2.3.9.1 (/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19.x86_64) The JDK is configured globally using the Windows path (the master also runs jobs) and is overridden for the slave.
In our environment when we run jobs that use the SBT plug-in the system drive root from the master is pre-pended to the sbt-launcher command line even though sbt-launcher is being invoked on the slave. The command-line looks like this:
C:\lib\jvm\java-7-openjdk-amd64\bin\java -Dsbt.log.noformat=true -Dcbs=true -jar /opt/wt-sbt/sbt/0.12.0/sbt-launch.jar clean
I believe the crux of the issue is with the use of java.io.File objects. The absolute path to the java executable will have a Windows feel to it when the master is hosted on a Windows system. This is a bit of a problem in hudson.model.JDK as well where getBinDir() returns a File object.