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

Node variables not passed through to Maven jobs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Platform: PC, OS: Windows XP
    • Similar Issues:

      Description

      Hudson 1.315 running in Tomcat 6, 64-bit Java 1.6.0_14 JVM, on Win2k3 server.

      Environment variables set in the main Hudson configuration are not passed to
      Maven tasks, neither are they available for use in options (e.g. MAVEN_OPTS)

      MAVEN_OPTS as defined in the job is passed directly to the JVM via the command
      line. Inserting %MAVEN_OPTS% (Windows style) or $MAVEN_OPTS or ${MAVEN_OPTS} as
      suggested in help popout do not expand the existing variable, but instead get
      inserted as literal text, stopping the process.

      Verified by running Maven help:system goal. This lists Java system properties
      and environment variables. Neither MAVEN_OPTS or the test TEST_STUPID_VAR were
      present, and the effects that MAVEN_OPTS should have on the JVM properties (in
      particular settings file.encoding) were not present either.

      This in direct contradiction of the release notes, which say that this should
      work. Reviewing the patch quoted at the bottom of issue 3644 this only seems to
      apply to the M2 release plugin.

      To be honest, I would have expected all environment variables defined in the
      Hudson config to be visible to all processes forked from Hudson - or else what's
      the point of having them at all? Environment expansion in all job settings is a
      natural convenience, and being able to also set environment variables in job
      types would also be useful.

        Attachments

          Activity

          Hide
          awilkins awilkins added a comment -

          If you set the system environment variable MAVEN_OPTS, that value is then
          available for expansion, but you have to explicitly specify that you want to use it

          e.g.

          I set MAVEN_OPTS=-Dfile.encoding=utf-8

          Running a mvn help:system build tells me that my file.encoding is Cp1252

          Then I configure that job to have MAVEN_OPTS of ${MAVEN_OPTS} and run again. My
          file.encoding is now utf-8 as intended.

          Maven jobs should use MAVEN_OPTS if it's defined in the environment. And the
          environment should include variables defined by Hudson.

          Show
          awilkins awilkins added a comment - If you set the system environment variable MAVEN_OPTS, that value is then available for expansion, but you have to explicitly specify that you want to use it e.g. I set MAVEN_OPTS=-Dfile.encoding=utf-8 Running a mvn help:system build tells me that my file.encoding is Cp1252 Then I configure that job to have MAVEN_OPTS of ${MAVEN_OPTS} and run again. My file.encoding is now utf-8 as intended. Maven jobs should use MAVEN_OPTS if it's defined in the environment. And the environment should include variables defined by Hudson.
          Hide
          awilkins awilkins added a comment -

          More experimentation ;

          You can't use environment variables to composite options for Maven (on Windows
          at least, don't know about Linux).

          The string you configure in MAVEN_OPTS is passed literally to the command line,
          it seems. It doesn't like ${MAVEN_OPTS} - it overruns into the next option (so
          you get errors like

          [uk_ace_bdb] $ "C:\Program Files\Java\jdk1.6.0_14/bin/java" ${MAVEN_OPTS} -Xmx4g
          -XX:+UseCompressedOops -Xmx4g -XX:+UseCompressedOops -cp
          d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-agent-1.315.jar;D:\apps\Apache\maven-2.2.0\boot\classworlds-1.1.jar
          hudson.maven.agent.Main D:\apps\Apache\maven-2.2.0
          D:\apps\Apache\Tomcat\webapps\hudson\WEB-INF\lib\remoting-1.315.jar
          d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.315.jar 1362
          Error occurred during initialization of VM
          java.nio.charset.IllegalCharsetNameException: utf-8 -Xmx4g -XX:+UseCompressedOops

          and

          [uk_ace_bdb] $ "C:\Program Files\Java\jdk1.6.0_14/bin/java" -Xmx4g
          -XX:+UseCompressedOops -Xmx4g -XX:+UseCompressedOops ${MAVEN_OPTS} -cp
          d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-agent-1.315.jar;D:\apps\Apache\maven-2.2.0\boot\classworlds-1.1.jar
          hudson.maven.agent.Main D:\apps\Apache\maven-2.2.0
          D:\apps\Apache\Tomcat\webapps\hudson\WEB-INF\lib\remoting-1.315.jar
          d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.315.jar 1409
          Could not create the Java virtual machine.
          Invalid maximum heap size: -Xmx4g -XX:+UseCompressedOops -Dfile.encoding=utf-8

          Show
          awilkins awilkins added a comment - More experimentation ; You can't use environment variables to composite options for Maven (on Windows at least, don't know about Linux). The string you configure in MAVEN_OPTS is passed literally to the command line, it seems. It doesn't like ${MAVEN_OPTS} - it overruns into the next option (so you get errors like [uk_ace_bdb] $ "C:\Program Files\Java\jdk1.6.0_14/bin/java" ${MAVEN_OPTS} -Xmx4g -XX:+UseCompressedOops -Xmx4g -XX:+UseCompressedOops -cp d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-agent-1.315.jar;D:\apps\Apache\maven-2.2.0\boot\classworlds-1.1.jar hudson.maven.agent.Main D:\apps\Apache\maven-2.2.0 D:\apps\Apache\Tomcat\webapps\hudson\WEB-INF\lib\remoting-1.315.jar d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.315.jar 1362 Error occurred during initialization of VM java.nio.charset.IllegalCharsetNameException: utf-8 -Xmx4g -XX:+UseCompressedOops and [uk_ace_bdb] $ "C:\Program Files\Java\jdk1.6.0_14/bin/java" -Xmx4g -XX:+UseCompressedOops -Xmx4g -XX:+UseCompressedOops ${MAVEN_OPTS} -cp d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-agent-1.315.jar;D:\apps\Apache\maven-2.2.0\boot\classworlds-1.1.jar hudson.maven.agent.Main D:\apps\Apache\maven-2.2.0 D:\apps\Apache\Tomcat\webapps\hudson\WEB-INF\lib\remoting-1.315.jar d:\hudson-home\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.315.jar 1409 Could not create the Java virtual machine. Invalid maximum heap size: -Xmx4g -XX:+UseCompressedOops -Dfile.encoding=utf-8
          Hide
          mdonohue mdonohue added a comment -

          Clarifying summary

          Show
          mdonohue mdonohue added a comment - Clarifying summary
          Hide
          emmulator emmulator added a comment -

          I just tested this, and Ant does get the variables, but not Maven. I get the
          same results as awilkins when I create a Job with "mvn help:system" – i.e. it
          shows that the global and node environment variables are not visible to Maven.
          But I created a simple Ant job with just the following build.xml:

          <project name="sample" default="test" >
          <property environment="env"/>
          <target name="test">
          <echo message="Home Dir: ${env.HOME}" />
          <echo message="Global Var: ${env.TEST_GLOBAL}" />
          <echo message="Node Var: ${env.PORT_PREFIX}" />
          </target>
          </project>

          And the console output for the job is:

          Buildfile: build.xml

          test:
          [echo] Home Dir: /home/cruise
          [echo] Global Var: global_value
          [echo] Node Var: 110

          I'll poke around a bit and see if I can figure out how the variables get to the
          Ant Job and see if I can apply the same logic to the Maven Job...

          Show
          emmulator emmulator added a comment - I just tested this, and Ant does get the variables, but not Maven. I get the same results as awilkins when I create a Job with "mvn help:system" – i.e. it shows that the global and node environment variables are not visible to Maven. But I created a simple Ant job with just the following build.xml: <project name="sample" default="test" > <property environment="env"/> <target name="test"> <echo message="Home Dir: ${env.HOME}" /> <echo message="Global Var: ${env.TEST_GLOBAL}" /> <echo message="Node Var: ${env.PORT_PREFIX}" /> </target> </project> And the console output for the job is: Buildfile: build.xml test: [echo] Home Dir: /home/cruise [echo] Global Var: global_value [echo] Node Var: 110 I'll poke around a bit and see if I can figure out how the variables get to the Ant Job and see if I can apply the same logic to the Maven Job...
          Hide
          emmulator emmulator added a comment -

          Ah, I see mdonohue just said the same thing as my last update by changing the
          summary.

          Show
          emmulator emmulator added a comment - Ah, I see mdonohue just said the same thing as my last update by changing the summary.
          Hide
          emmulator emmulator added a comment -

          Created an attachment (id=967)
          Patch file

          Show
          emmulator emmulator added a comment - Created an attachment (id=967) Patch file
          Hide
          emmulator emmulator added a comment -

          I didn't want to submit this one directly to SVN without some review, since I'm
          not sure what all the ramifications might be, but the above patch just adds a
          'createLauncher' method to MavenModuleSetBuild.RunnerImpl. It is patterned on
          the same method from Build.RunnerImpl, which is where it seemed to me that the
          other Build types were geting the Global and Node-based environment variables
          from. This patch works for me, and I am now able to use the Node-based
          Environment variables in my Maven "Goals and Options" command.

          Show
          emmulator emmulator added a comment - I didn't want to submit this one directly to SVN without some review, since I'm not sure what all the ramifications might be, but the above patch just adds a 'createLauncher' method to MavenModuleSetBuild.RunnerImpl. It is patterned on the same method from Build.RunnerImpl, which is where it seemed to me that the other Build types were geting the Global and Node-based environment variables from. This patch works for me, and I am now able to use the Node-based Environment variables in my Maven "Goals and Options" command.
          Hide
          abayer Andrew Bayer added a comment -

          This was fixed at some point since the last update to the issue - I'm not honestly sure when. But I've verified that node environment variables are properly available to Maven now.

          Show
          abayer Andrew Bayer added a comment - This was fixed at some point since the last update to the issue - I'm not honestly sure when. But I've verified that node environment variables are properly available to Maven now.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            awilkins awilkins
            Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: