• Icon: Improvement Improvement
    • Resolution: Not A Defect
    • Icon: Major Major
    • m2release-plugin
    • None
    • Platform: All, OS: All

      We have maven jobs that require specific MAVEN_OPTS to be able to complete
      successfully.

      One example is to be able to specify the -Xmx parameter to the JVM to workaround
      memory problems in the artifact deployer (which apparently pulls the whole
      artifact in memory to upload it, a problem for large artifacts).

      The configuration page for maven2 projects in Hudson lets you specify the
      MAVEN_OPTS to use in the Advanced Build options.

      One way to support support these in the m2release plugin would be to
      automatically use whatever MAVEN_OPTS are specified for the job in the Advanced
      Build option, if any.
      Another way would be to allow us to specify the MAVEN_OPTS to use for m2release
      somewhere in the configuration, either globally or per-project.

      Thanks!

          [JENKINS-3644] Support for MAVEN_OPTS in release builds

          odony created issue -

          odony added a comment -

          Created an attachment (id=691)
          A sample failed m2release build log due to lack of MAVEN_OPTS, as requested by james

          odony added a comment - Created an attachment (id=691) A sample failed m2release build log due to lack of MAVEN_OPTS, as requested by james

          James Nord added a comment -

          The log you attached doesn't show any Maven_Opts being set.

          In my test it shows
          [trunk] $ "C:\Program Files\Java\jdk1.6.0_07/bin/java" -Xmx256M -cp ....

          Are you saying even if you supply MAVEN_OPTS as "-Xmx512M -Xms256M" the release
          fails to pick this up?

          James Nord added a comment - The log you attached doesn't show any Maven_Opts being set. In my test it shows [trunk] $ "C:\Program Files\Java\jdk1.6.0_07/bin/java" -Xmx256M -cp .... Are you saying even if you supply MAVEN_OPTS as "-Xmx512M -Xms256M" the release fails to pick this up?

          odony added a comment -

          Well, after trying to reproduce this myself, I can indeed see that the
          MAVEN_OPTS parameters that I set in the maven build options for the job are
          indeed passed during the release. D'oh!

          I forwarded the log file without trying to reproduce it myself!
          Likely explanation: the maven build does not fail for a normal build, but only
          during releases (due to the OOM during artifact deployment), so we did not
          double check the MAVEN_OPTS, having already set such MAVEN_OPTS for other jobs
          to fix regular builds that did need it.
          We had also found other workarounds in the mean time, so we had not tried this
          approach again.

          Anyway, thanks a lot for your time, and sorry about the useless bugreport.

          Of course a real solution for this would be for the maven plugin in charge of
          package deployment to fix this annoying OOM bug, and/or to be able to set global
          MAVEN_OPTS for Hudson (which does not seem to work currently in the Hudson
          preferences). But I'll take these elsewhere...

          Please delete this issue if the system allows you to, or close it as INVALID.

          odony added a comment - Well, after trying to reproduce this myself, I can indeed see that the MAVEN_OPTS parameters that I set in the maven build options for the job are indeed passed during the release. D'oh! I forwarded the log file without trying to reproduce it myself! Likely explanation: the maven build does not fail for a normal build, but only during releases (due to the OOM during artifact deployment), so we did not double check the MAVEN_OPTS, having already set such MAVEN_OPTS for other jobs to fix regular builds that did need it. We had also found other workarounds in the mean time, so we had not tried this approach again. Anyway, thanks a lot for your time, and sorry about the useless bugreport. Of course a real solution for this would be for the maven plugin in charge of package deployment to fix this annoying OOM bug, and/or to be able to set global MAVEN_OPTS for Hudson (which does not seem to work currently in the Hudson preferences). But I'll take these elsewhere... Please delete this issue if the system allows you to, or close it as INVALID.

          James Nord added a comment -

          this seems to work marking INVALID

          James Nord added a comment - this seems to work marking INVALID
          James Nord made changes -
          Resolution New: Incomplete [ 4 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          James Nord added a comment -

          actually the forked maven invocations don't pick this up.

          A quick and dirty showed that hudson isn't setting MAVEN_OPTS but just passing
          the arguments to the java process.

          The correct place for this fix is in Hudson core, but I'll try and put a
          workaround in.

          James Nord added a comment - actually the forked maven invocations don't pick this up. A quick and dirty showed that hudson isn't setting MAVEN_OPTS but just passing the arguments to the java process. The correct place for this fix is in Hudson core, but I'll try and put a workaround in.
          James Nord made changes -
          Resolution Original: Incomplete [ 4 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          Code changed in hudson
          User: : teilo
          Path:
          trunk/hudson/plugins/m2release/src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=19423
          Log:
          [FIXED JENKINS-3644] Explicitly set the EvironmentVariable MAVEN_OPTS so it is inherited by forked maven processes - like the release plugin

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : teilo Path: trunk/hudson/plugins/m2release/src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java http://fisheye4.cenqua.com/changelog/hudson/?cs=19423 Log: [FIXED JENKINS-3644] Explicitly set the EvironmentVariable MAVEN_OPTS so it is inherited by forked maven processes - like the release plugin
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Reopened [ 4 ] New: Resolved [ 5 ]

            Unassigned Unassigned
            odony odony
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: