• 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 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 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.

          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

          James Nord added a comment -

          marking closed

          James Nord added a comment - marking closed

          Indra Gunawan added a comment -

          What is the workaround here?

          I set "MAVEN_OPTS" as env variable using the EnvInject plug-in but the maven release still runs into OOM PermGen.
          Jenkins version : 1.544.3
          m2Release plugin version: 0.14
          Maven Project plugin version 2.7.1

          -Indra

          Indra Gunawan added a comment - What is the workaround here? I set "MAVEN_OPTS" as env variable using the EnvInject plug-in but the maven release still runs into OOM PermGen. Jenkins version : 1.544.3 m2Release plugin version: 0.14 Maven Project plugin version 2.7.1 -Indra

          Indra Gunawan added a comment -

          I am getting the same error.

          I have set the MAVEN_OPTS to the build environment section of the job via EnvInject but it is not passed to the maven release.

          The m2/3 type job does clean deploy with "-Xms512m –Xmx2048m” MAVEN_OPTS.
          I am setting the MAVEN_OPTS again in Build Environment -> Inject environment variables to the build process” : MAVEN_OPTS='-Xms512m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m’

          However the maven release is still failing with OOM PermGen.

          I see this in the console:

          At revision 154784
          [EnvInject] - Executing scripts and injecting environment variables after the SCM step.
          [EnvInject] - Injecting as environment variables the properties content
          MAVEN_OPTS='-Xms512m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m’

          [checkout] $ /users/px-build/commonTools/java/jdk1.7.0_67/LNX-64/bin/java -Xms512m -Xmx2048m -cp /scratch/jenkins_slave_sjc-bld62-lnx/maven3-agent.jar:/users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4 /scratch/jenkins_slave_sjc-bld62-lnx/slave.jar /scratch/jenkins_slave_sjc-bld62-lnx/maven3-interceptor.jar /scratch/jenkins_slave_sjc-bld62-lnx/maven3-interceptor-commons.jar 38360

          Executing Maven: -B -f /scratch/jenkins_slave_sjc-bld62-lnx/workspace/comp-ps_cluster_parent-PI_3_0_NIHAU/checkout/pom.xml -Dmaven.repo.local=/scratch/jenkins_slave_sjc-bld62-lnx/workspace/comp-ps_cluster_parent-PI_3_0_NIHAU/.repository -DdevelopmentVersion=3.0.29-SNAPSHOT -DreleaseVersion=3.0.28 -e -B -Prelease-profile -DgenerateReleasePoms=true release:prepare release:perform -Dresume=false -s /users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4/conf/settings-rel.xml -Dmaven.test.skip=true

          -Indra

          Indra Gunawan added a comment - I am getting the same error. I have set the MAVEN_OPTS to the build environment section of the job via EnvInject but it is not passed to the maven release. The m2/3 type job does clean deploy with "-Xms512m –Xmx2048m” MAVEN_OPTS. I am setting the MAVEN_OPTS again in Build Environment -> Inject environment variables to the build process” : MAVEN_OPTS='-Xms512m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m’ However the maven release is still failing with OOM PermGen. I see this in the console: At revision 154784 [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content MAVEN_OPTS='-Xms512m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m’ … [checkout] $ /users/px-build/commonTools/java/jdk1.7.0_67/LNX-64/bin/java -Xms512m -Xmx2048m -cp /scratch/jenkins_slave_sjc-bld62-lnx/maven3-agent.jar:/users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4 /scratch/jenkins_slave_sjc-bld62-lnx/slave.jar /scratch/jenkins_slave_sjc-bld62-lnx/maven3-interceptor.jar /scratch/jenkins_slave_sjc-bld62-lnx/maven3-interceptor-commons.jar 38360 … Executing Maven: -B -f /scratch/jenkins_slave_sjc-bld62-lnx/workspace/comp-ps_cluster_parent-PI_3_0_NIHAU/checkout/pom.xml -Dmaven.repo.local=/scratch/jenkins_slave_sjc-bld62-lnx/workspace/comp-ps_cluster_parent-PI_3_0_NIHAU/.repository -DdevelopmentVersion=3.0.29-SNAPSHOT -DreleaseVersion=3.0.28 -e -B -Prelease-profile -DgenerateReleasePoms=true release:prepare release:perform -Dresume=false -s /users/px-build/commonTools/maven/sjc-hudson62-lnx/apache-maven-3.0.4/conf/settings-rel.xml -Dmaven.test.skip=true … -Indra

          Indra Gunawan added a comment -

          Would you please explain where should the env variable MAVEN_OPTS be added to Jenkins so the m2release can pick it up in the m2/3 type job.

          Thank you
          -Indra

          Indra Gunawan added a comment - Would you please explain where should the env variable MAVEN_OPTS be added to Jenkins so the m2release can pick it up in the m2/3 type job. Thank you -Indra

          I am facing exactly the same problem, would you mind to explain how to patch this?
          My sonar builds are failing.
          Thanks

          Francois LE FEVRE added a comment - I am facing exactly the same problem, would you mind to explain how to patch this? My sonar builds are failing. Thanks

          James Nord added a comment - - edited

          This is a misconfiguration on your maven side and a bug in Maven.
          Until someone demonstrates otherwise with a correctly configured pom a log from jenkins showing it not working and a log from the command line showing it working.
          (note in jenkins you will need more memory and permgen configured due to the classes and inspection it performs)
          Ask on the maven mailing list how to pass environment variables to the forked release invocation.

          James Nord added a comment - - edited This is a misconfiguration on your maven side and a bug in Maven. Until someone demonstrates otherwise with a correctly configured pom a log from jenkins showing it not working and a log from the command line showing it working. (note in jenkins you will need more memory and permgen configured due to the classes and inspection it performs) Ask on the maven mailing list how to pass environment variables to the forked release invocation.

          James Nord added a comment -

          James Nord added a comment - Hint http://bfy.tw/2Wg7

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

              Created:
              Updated:
              Resolved: