• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Major Major
    • core, m2release-plugin
    • None
    • Issue encountered on "cloudbees"

      For some reasons, I need to compile my code with JDK 1.5. I configured a Hudson job with this version and I also configured the maven enforcer plugin to check if the proper JDK is used.

      When I do a release I get this error, obviously I don't use during release the JDK configured for the job :

      FO] [INFO] [enforcer:enforce

      {execution: enforce-versions}

      ]
      [INFO] [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireJavaVersion
      [INFO] [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireJavaVersion is cacheable.
      [INFO] [DEBUG] Detected Java String: 1.6.0_20
      [INFO] [DEBUG] Normalized Java String: 1.6.0-20
      [INFO] [DEBUG] Parsed Version: Major: 1 Minor: 6 Incremental: 0 Build: 20 Qualifier: null
      [INFO] [INFO] ------------------------------------------------------------------------
      [INFO] [ERROR] BUILD ERROR
      [INFO] [INFO] ------------------------------------------------------------------------
      [INFO] [INFO] org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
      [INFO] Detected JDK Version: 1.6.0-20 is not in the allowed range [1.5,1.6).
      [INFO]
      [INFO] [INFO] ------------------------------------------------------------------------
      [INFO] [DEBUG] Trace
      [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
      [INFO] Detected JDK Version: 1.6.0-20 is not in the allowed range [1.5,1.6).

          [JENKINS-7886] Use the JDK configured for the job

          pascalleclercq created issue -

          James Nord added a comment -

          Can you attach a dump of the node environment?

          JAVA_HOME should be set correctly.

          James Nord added a comment - Can you attach a dump of the node environment? JAVA_HOME should be set correctly.

          vivekp added a comment -

          Looks like m2release plugin does let override JAVA_HOME setting over the project level JDK selection. Here is how I can reproduce it:

          I have JAVA_HOME to JDK6 setting under configure hudson screen. Then in my project I select JDK5.

          When the build happens, mvn release:prepare is invoked using JAVA_HOME rather than the JDK selected at the project level. This seems like a bug or clearly not as ones expectation would be. Basically project level JDK setting should override the JAVA_HOME setting anywhere else.

          Looking inside m2release plugin source code, M2ReleaseBuildWrapper:buildEnvVars() has this code commented out,

          /*
          if (!env.containsKey("JAVA_HOME"))

          { env.put("JAVA_HOME", mmSet.getJDK().getHome()); }

          */

          Maybe this is not what the fix is. Someway it needs to indicate what JDK to use. I thin the project JDK can be obtained from Build inside setup() method. I have attached a mvn testcase to reproduce this issue. Simply create a maven2 job and point to the pom file, set JAVA_HOME at the global level as mentioned above.

          vivekp added a comment - Looks like m2release plugin does let override JAVA_HOME setting over the project level JDK selection. Here is how I can reproduce it: I have JAVA_HOME to JDK6 setting under configure hudson screen. Then in my project I select JDK5. When the build happens, mvn release:prepare is invoked using JAVA_HOME rather than the JDK selected at the project level. This seems like a bug or clearly not as ones expectation would be. Basically project level JDK setting should override the JAVA_HOME setting anywhere else. Looking inside m2release plugin source code, M2ReleaseBuildWrapper:buildEnvVars() has this code commented out, /* if (!env.containsKey("JAVA_HOME")) { env.put("JAVA_HOME", mmSet.getJDK().getHome()); } */ Maybe this is not what the fix is. Someway it needs to indicate what JDK to use. I thin the project JDK can be obtained from Build inside setup() method. I have attached a mvn testcase to reproduce this issue. Simply create a maven2 job and point to the pom file, set JAVA_HOME at the global level as mentioned above.

          vivekp added a comment -

          Testcase.

          vivekp added a comment - Testcase.
          vivekp made changes -
          Attachment New: mvntest.zip [ 19905 ]

          James Nord added a comment -

          JAVA_HOME should be set by JDK.getEnvVars() so we should not anything special in the plugin (hence it is comented out).

          Indeed - this is working for me.

          When you say you have set "JAVA_HOME to JDK6 setting under configure hudson screen" can you explain what you have set?

          I will do some more digging but this may be a core bug in the way environment variables are not set correctly

          James Nord added a comment - JAVA_HOME should be set by JDK.getEnvVars() so we should not anything special in the plugin (hence it is comented out). Indeed - this is working for me. When you say you have set "JAVA_HOME to JDK6 setting under configure hudson screen" can you explain what you have set? I will do some more digging but this may be a core bug in the way environment variables are not set correctly

          In the picture attached, you can see a JDK 5 configured for the build (which is the JDK I want to use during the release also). But If I execute a release, then the JDK 6 (I suppose the platform's default) is used.

          Regards

          pascalleclercq added a comment - In the picture attached, you can see a JDK 5 configured for the build (which is the JDK I want to use during the release also). But If I execute a release, then the JDK 6 (I suppose the platform's default) is used. Regards
          pascalleclercq made changes -
          Attachment New: hudson_cfg.jpg [ 19927 ]

          James Nord added a comment -

          Something fishy..

          James Nord added a comment - Something fishy..
          James Nord made changes -
          Link New: This issue is related to JENKINS-8092 [ JENKINS-8092 ]

            Unassigned Unassigned
            pascalleclercq pascalleclercq
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: