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

Hudson does not set JAVA_HOME for Maven Builds

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • maven-plugin
    • None

      Hudson uses the configured JDK for a maven build but does not set the JAVA_HOME property. So if you try to make a release the prepare is executed against the configured jdk but the perform is executed against the default JDK.

      We have a couple of builds which depends on the IBM JDK. We have configured whe jobs appropriately and it is working for snapshot builds. When running a release build the JDK tomcat is running on (Sun JDK) is used instead.

      When we set the JAVA_HOME explicitely in the job it works. But this is a mess as we have to enter the full path to the jdk (and this is not the same on all slaves).

      Hudson should set JAVA_HOME for the current build or - at least - provide a variable which holds the path to the configured JDK.

      This a blocking issue at our site!

          [JENKINS-6763] Hudson does not set JAVA_HOME for Maven Builds

          Vincent Latombe added a comment - Hello, have you checked http://wiki.jenkins-ci.org/display/JENKINS/Tool+Environment+Plugin ?

          micha4311 added a comment -

          Thanks for the suggestion. I saw this plugin on my research but found that it is not the best way as it does not export JAVA_HOME but something like SUN_1_6_HOME - so we need an additional config like exporting a parameter 'JAVA_HOME' with the value 'SUN_1_6_HOME'.

          I will check if it could be used as a workaround Indeed it is better as we do not need to know the full path (and only need to know the transformation algorithm from the JDKs name).

          For a long term solution the JAVA_HOME should be exported as it does not make any sense to NOT export it.

          micha4311 added a comment - Thanks for the suggestion. I saw this plugin on my research but found that it is not the best way as it does not export JAVA_HOME but something like SUN_1_6_HOME - so we need an additional config like exporting a parameter 'JAVA_HOME' with the value 'SUN_1_6_HOME'. I will check if it could be used as a workaround Indeed it is better as we do not need to know the full path (and only need to know the transformation algorithm from the JDKs name). For a long term solution the JAVA_HOME should be exported as it does not make any sense to NOT export it.

          micha4311 added a comment -

          I tried the tool environment plugin but failed to set JAVA_HOME for the calling process. It seems that I cannot use the exporter SUN_1_6_HOME variable as a build parameter. Additionally everyone doing a manual build would be in need to 'skip' the parameters page

          micha4311 added a comment - I tried the tool environment plugin but failed to set JAVA_HOME for the calling process. It seems that I cannot use the exporter SUN_1_6_HOME variable as a build parameter. Additionally everyone doing a manual build would be in need to 'skip' the parameters page

          micha4311 added a comment -

          I found out a little more and it seems to be a little more complex than originally thought.

          Hudson DOES define the used JDK as JAVA_HOME. This is working when the build runs on the master.

          When running on a slave (we use the ssh-slaves-plugin) this Environment-setting is lost. On the slave-configuration-page we define an environment variable JAVA_HOME (needed so that hudson is able to start the slave as java is not on the path) and every build on the slaves uses this variable.

          micha4311 added a comment - I found out a little more and it seems to be a little more complex than originally thought. Hudson DOES define the used JDK as JAVA_HOME. This is working when the build runs on the master. When running on a slave (we use the ssh-slaves-plugin) this Environment-setting is lost. On the slave-configuration-page we define an environment variable JAVA_HOME (needed so that hudson is able to start the slave as java is not on the path) and every build on the slaves uses this variable.

          micha4311 added a comment -

          We currently did a workaround with a combination of Tool Environment Plugin and SetEnv Plugin:

          • let Tool Environment Plugin export the java-Home (uses something like SUN_1_6_HOME)
          • let SetEnv export JAVA_HOME=${SUN_1_6_HOME}

          it works for us as the job configs are created automatically. Otherwise it would be ugly as you have to define the used jdk twice which is error prone

          micha4311 added a comment - We currently did a workaround with a combination of Tool Environment Plugin and SetEnv Plugin: let Tool Environment Plugin export the java-Home (uses something like SUN_1_6_HOME) let SetEnv export JAVA_HOME=${SUN_1_6_HOME} it works for us as the job configs are created automatically. Otherwise it would be ugly as you have to define the used jdk twice which is error prone

          Damon Overboe added a comment - - edited

          On Jenkins 1.575, working against Windows Server 2012, setting the JDK in Jenkins provides the option to input the JAVA_HOME variable, and that worked around the issue for me.

          This might be what you were referring to as having it set twice, but given that it seems to completely ignore JAVA_HOME on the clients (even though it reports that correctly with the script console) it doesn't seem to cause any issues.

          Here were my steps:

          1. Manage Jenkins
          2. Configure System
          3. Scroll to JDK installations
          4. Add JDK Installation
          5. Provide JAVA_HOME path to the JDK folder on the client/slave
            such as C:\Progra~2\Java\jdk1.7.0_67 where Proga~2 resolves to Program Files (x86)

          Damon Overboe added a comment - - edited On Jenkins 1.575, working against Windows Server 2012, setting the JDK in Jenkins provides the option to input the JAVA_HOME variable, and that worked around the issue for me. This might be what you were referring to as having it set twice, but given that it seems to completely ignore JAVA_HOME on the clients (even though it reports that correctly with the script console) it doesn't seem to cause any issues. Here were my steps: Manage Jenkins Configure System Scroll to JDK installations Add JDK Installation Provide JAVA_HOME path to the JDK folder on the client/slave such as C:\Progra~2\Java\jdk1.7.0_67 where Proga~2 resolves to Program Files (x86)

            Unassigned Unassigned
            micha4311 micha4311
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: