Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View Maven Release Plug-in on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin allows you to perform a release build using the maven-release-plugin from within Jenkins.

Project Configuration

On the job configuration page, enable the "Maven release build" under the Build Environment heading and add whatever release goals and options your require.

Performing a Release Build

Follow the "Perform Maven Release" link

and choose "Schedule Maven Release Build".

Using with Nexus Staging

Nexus staging will create a new Stage for each unique IP Address, deploy users and HTTP User agent.

For a particular Jenkins slave the first two will be the same for all builds - so you need to configure Maven to use a unique HTTP User-Agent for the deploy.

To do this make sure your maven settings contains something like the following where the id matches the id for the release repository in the deployment section of your project:

          <value>Maven m2Release (java:${java.vm.version} ${env.BUILD_TAG }</value>


If your build fails with the following:

INFO Executing: mvn clean verify --no-plugin-updates --batch-mode -P null,null
'mvn' is not recognized as an internal or external command,
operable program or batch file.

Then this is a maven bug not a Jenkins plug-in bug.
The solution is to upgrade to version 2.0-beta-8 or later of the maven-release-plugin in your project.

Some users with CVS (cvs+ssh) have reported that a release just hangs while accessing the ssh server (JENKINS-4783). The solution is to use the native CVS client and append "-Dmaven.scm.provider.cvs.implementation=cvs_native" to the release arguments.

The use of this plugin requires that Maven can tag your code.  You may need to use cvs/svn etc from the CI account on the server that is performing the release so the native tools used by maven have the required authentication information.  (this is outside of Jenkins SCM authentication)

Help and Support

For Help and support please use the Jenkins Users mailing list.
To report a bug please check the bug tracker to see if the issue has been reported before creating a new issue.
The comment list below is not monitored.

Version History

0.16.0 (Not yet released)

build from source or download from here if interested

  • Fix JENKINS-35261 SCM username/password env variables don't work with SECURITY-170.
  • Fix JENKINS-16043 NullPointerException with {{FileParameter}}s
  • remove "Default versioning mode" from the UI as it does nothing currently.

0.15.0 (31 July 2019)

Security fixes (announcement)

0.14.0 (31 March 2014)

0.13.0 (23 December 2013)

  • Note the plugin now requires
    • Jenkins 1.509 or higher

0.12.0 (25th July 2013)

  • Fix Nexus integration after Sonatype changed public API (again) in 2.6

0.11.0 (4th July 2013)

  • Drop Hudson support. The Hudson community now build and maintain their own fork.
  • Note the plugin now requires
    • Jenkins 1.466 or higher
  • Fix Nexus integration after Sonatype changed public API in 2.4

0.10.0 (26th Apr 2013)

0.9.1 (1st Mar 2012)

0.9.0 (13th Feb 2012)

  • Note the plugin now requires
    • Jenkins 1.442 or higher
    • Jenkins LTS 1.424.2 or higher
    • Hudson with the maven-plugin 2.2.1 or higher
  • Fix JENKINS-10127 - M2 Release plugin ignores parameters from a parameterized build (thanks to Dominik Bartholdi for the patch)
  • Fix JENKINS-4690 - Be able to arbitrary paramterize m2 releases (thanks to Dominik Bartholdi for the patch)
  • Fix JENKINS-4500 - Make it possible to select a node to do the release on (together with the nodelabel-plugin) (thanks to Dominik Bartholdi for the patch)
  • Fix JENKINS-4958 - add switch for -DdryRun=true (thanks to Dominik Bartholdi for the patch)

0.8.1 (2nd November 2011)

  • Fix JENKINS-11238 Prevent log spam from when upgrading from an old version with a default versioning mode. (Patch from Richard Mortimer aka oldelvet)
  • Fix JENKINS-10661 Impossible to assign the permission release using project based matrix security

0.8.0 (4th October 2011)

  • Fix JENKINS-8293 - Disable auto refresh for the "Perform" screen to prevent entered password being removed. (Thanks to oldelvet for the patch)
  • Fix JENKINS-7295 JENKINS-5171 - Ability to override the SCM tag to use.
  • Removed ability to specify version for each module (it would faile to work correctly if Jenkins was not building every comit).
  • Removed ability to let maven devide the versioning (the version is needed for things like tooltips).

0.7.1 (10th March 2011)

  • Update plugin to show dependency on Jenkins >= 1.400 (to pick up the fixes below)

0.7.0 (10th March 2011)

  • Fix JENKINS-8289 - enforce dev Version to be a snapshot
  • Fix JENKINS-7837 - release does not use the maven installation it was configured with but whatever is on the path. (NB fixed in core - requires Jenkins >= 1.400)
  • Fix JENKINS-8092 - Maven release plugin cannot find mvn command. (NB fixed in core - requires Jenkins >= 1.400)
  • add permalink to last release.

0.6.1 (17th September 2010)

  • Fix JENKINS-7492 - Fix internal error which occurs under tomcat but not winston due to a double redirect.

0.6.0 (16th September 2010)

  • Fix JENKINS-3876 - Add an icon to release builds.
  • Fix JENKINS-6791 - Scheduling a release will fail silently if a build is already in the queue.

0.5.3 (12th July 2010)

  • Fix NPE when trying to close nexus state.

0.5.2 (8th July 2010)

  • Re-Fix JENKINS-6873 - After scheduling a release build a HTTP 404 error page can be displayed.

0.5.1 (30th June 2010)

  • Fix JENKINS-6887 - NPE during release when version is decided by Maven.
  • Fix JENKINS-6873 - After scheduling a release build a HTTP 404 error page can be displayed.

0.5.0 (25th June 2010)

0.4.0 (26th May 2010)

  • Fix JENKINS-5295 - plugin now allows you to pass SCM username/password to maven.
  • Fixed to work with Nexus 1.5.0 (authorization was not occuring correctly).
  • Added support for specifying an exact version to use across all modules (JENKINS-3429).
  • Added support for specifying scmCommentPrefix (issue #4127 ).
  • Added support for appending the Jenkins username to the scmCommentPrefix (optional).
  • Added config settings (per project) which option(s) should be enabled by default for the Release Action.

0.3.4 (29th December 2009)

  • Fix help pages not showing up when Jenkins runs on a case sensitive file system.
  • Use POST instead of GET to avoid long form URLs.

0.3.3 (21th August 2009)

  • Fix JENKINS-4172 that prevented Jenkins upgrades working correctly.

0.3.2 (24th July 2009)

  • (0.3.0 & 0.3.1 were not released)
  • Jenkins doesn't set the MAVEN_OPTS variable so added a workaround in the plugin JENKINS-3644
  • Added a sepcific security right to allow fine grained release permissions.
  • Added support for closing Nexus Pro staging repository after a release.
  • Added some synchronization to protect against a theoretical race condition.
  • Fix JENKINS-4065 that caused the release plugin to blow up when releases where n-SNAPSHOT.

0.2.0 (23rd March 2009)

  • Added support for Jenkins Security (only users who can perform a manual build can trigger a release build).
  • Release goals now default to -Dresume=false release:prepare release:perform.
  • Added support for specifying exact versions to use.
  • Added support for appending Jenkins build number as maven build number qualifier.
  • Integrated with Jenkins security.  Users require "Build" rights in order to create a release
  • Requires Jenkins >= 1.292.

0.1.0 (16th March 2009)

  • Initial version.
  • Can only use the auto versioning feature of the maven-release-plugin.
  • Tested with a simple single module project, in a master only Jenkins environment.
  • Requires Huson >= 1.288.


In no order:

  • Integrate with Jenkins security model.
  • Add support for specifying exact versions to use.
  • Add support for auto-versioning with Jenkins build number as maven build number qualifier.
  • Add a sepcific security right to produce a release build.
  • Add support to clean workspace before a release build is performed for the case where Jenkins uses update (JENKINS-3925).
  • work in progress: Add support to clean local maven repository before a release build is performed. Useful for guaranteeing the release is buildable from scratch.
  • Update wiki and add help for latest features.
  • Check compatability with Jenkins master/slave.
  • Check compatability with multi-module projects.
  • Add some feedback onto the build history to show release builds (like the Release Plugin).
  • Get jenkins to recognize the releases as build artifacts.
  • See if we can do something in the freestyle for maven builds.
  • Nexus support
    • rewrite support from ground up to avoid closing incorrect repository
    • Add support for closing nexus pro staging repos on succesful build completion.
    • Add support (if possible) for changing the User agent to support grouping into a nexus pro staging repo.
    • Add support for removing a nexus pro staging repo on a failed build.
    • Add support for auto promoting a nexus pro staging repo on a successful build.


  1. Unknown User (retronym)

    When I originally tried this plugin, I always hit this error. After upgrading to Maven 2.1.0 and Hudson 1.306, it works perfectly.

    [INFO] Checking out the project to perform the release ...
    [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout http://chzrhfpmon01/repos/efg-commons/efg-commons-io/tags/efg-commons-io-0.4 d:\work\hudson_home\jobs\efg-commons-io\workspace\efg-commons-io\target\checkout"
    [INFO] Working directory: d:\work\hudson_home\jobs\efg-commons-io\workspace\efg-commons-io\target
    [INFO] Executing goals 'deploy site-deploy'...
    [INFO] [INFO] Scanning for projects...
    [INFO] [INFO] ------------------------------------------------------------------------
    [INFO] [INFO] Building Maven Default Project
    [INFO] [INFO]    task-segment: [deploy, site-deploy]
    [INFO] [INFO] ------------------------------------------------------------------------
    [INFO] [INFO] Ignoring available plugin update: 2.5 as it requires Maven version 2.0.9
    [INFO] [INFO] ------------------------------------------------------------------------
    [INFO] [INFO] ------------------------------------------------------------------------
    [INFO] [INFO] Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.
  2. Unknown User (gabriel.falkenberg@gmail.com)

    We got the following error while trying to use the M2-release plugin:

    [INFO] Unable to commit files
    Provider message:
    The svn command failed.
    Command output:
    svn: Commit failed (details follow):
    svn: OPTIONS of 'http://example.com/test-repo/branches/release_1_1': authorization failed (http://example.com)

    The solution was to login as the user running Hudson and performing a couple of svn commands (such as list) from the command line on the repo in question. This is mentioned (performing some svn commands manually) on the page: http://wiki.jenkins-ci.org/display/HUDSON/Hosting+plugins but with no explanation of why this might solve anything. It might be that this caches the svn credentials for the user and maybe the release plugin forks a new process which does not use Hudson's saved svn credentials?

  3. Unknown User (dhartford)

    m2 release plugin 0.20 on hudson 1.288 breaks, and another symptom is when you configure a project with the release plugin, the configure page breaks where the release section just was, and you no longer have the ok/submit button.

    upgrading hudson to 1.307 corrects this issue.(this is all in the above notes btw).

  4. Unknown User (magullo)

    Do you think it would be difficult to implement version tagging (not the default one).

    Now I have to specify it as a -Dtag=tag in configuration.


  5. Unknown User (pringles)

    Can dependencies be specified using thisrelease plugin.like,

    you can trigger a release once a dependent one is released ?

  6. Unknown User (henryju)

    Please add a way to specify scmCommentPrefix like in Continuum. In my organisation we have a pre commit hook that enforce a specific bug tracker id in every SVN commit message. So the release plugin is not able to commit/tag without this information.


  7. Unknown User (bertrand gressier)

    It will be very good, if plugin begin to make a svn up before run release.

  8. Unknown User (bertrand gressier)

    I have a bug if my version is not "standard" : 1.3.5-4-SNAPSHOT

    In hudson log I have this message :
    Nov 6, 2009 3:32:31 PM hudson.ExpressionFactory2$JexlExpression evaluate
    WARNING: Caught exception evaluating: it.computeNextVersion(m.version). Reason: java.lang.NumberFormatException: For
    input string: "5-3"
    java.lang.NumberFormatException: For input string: "5-3"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:456)
    at java.lang.Integer.parseInt(Integer.java:497)
    at org.jvnet.hudson.plugins.m2release.M2ReleaseAction.computeNextVersion(M2ReleaseAction.java:98)

    And when the job is running, I have this error log :
    INFO Can't run goal clean verify

    java.io.IOException: mvn: not found


  9. Unknown User (edgar@info.nl)

    Thanks for this nice plugin.

    We have an issue however when we want to release one of our projects which has a large (>30) number of modules in it. When you select 'Specify release version(s)' the URL that the plugin generates (apparently it creates a GET request instead of a POST request) becomes too large:

    Request-URI Too Large
    The requested URL's length exceeds the capacity limit for this server.

    Is it possible for the plugin to use a POST request instead?

  10. Unknown User (fabrice@xeberon.net)

    thanks for the plugin

    • However why do you not propose to use SCM conf job for releasing instead of forcing user to declare SCM parameters in the pom.xml ?
    • BIG PROBLEM : you tag on the SCM with the job name suffixed by the release number. WHY ? Ex :
      INFO Tagging release with the label test-14-standard-web-1_0_0_0_3...

    Instead of tagging my test-14-standard-web with v1_0_0_0_3 as requested in the input release field before the release action.

    So because our SCM check the tag syntax the action is rejected :-(

    It is not the plugin but maven-release-plugin that is responsible of this

    (http://jira.codehaus.org/browse/MRELEASE-159, http://jira.codehaus.org/browse/MRELEASE-150)

    but How can I configure it

    I must give the -Dtag=v1_0_0_0_3 parameter to release:prepare but it will be fine if M2 release plugin could display on the action page, a input field with the SCM tag (with a default value)

    Can I create a issue ?

  11. Unknown User (abhi)

    anyone tried with perforce?? i am not able to use it...its failing while commit.

  12. Unknown User (batmat)

    Evaluating this plugin, I miss something that seems to me it would be not very difficult do add. In fact, most of the time, we release a whole hierarchy of multimodule projects with the same version for each module. We use the -DautoVersionSubModules=true option. At the moment, if I say I want to specify the versions, the plugin shows every single modules.

    To be able to use the hudson-m2 release plugin, it should add an additional option to say that the version is the same (the option above). This way, there would only one field for releaseVersion, and one for devVersion, not for each module.

    I could try and have a look at the plugin to do that myself. Do you think it would be difficult, and would you consider it a good improvement or would you reject it?


  13. Unknown User (simon.buss@vwfs.com)

    Hi James,

    we just switched to hudson and would really like to use your plugin for our releases. Your ToDo list says "

    • Get hudson to recognise the releases as build artifacts.


    Can you already foresee when you'll be able to get to that issue? To us it would be the one and most important issue to take the plugin into consideration for regular usage. So we would REALLY appreciate it being solved. BTW: I didn't find it in your JIRA Issues linked above, should I add it?

    The most appropriate way probably was to have hudson point to the maven repo where the released artifacts are deployed to. So maybe hudson/the plugin could just parse the m2 settings.xml and concatenate it with maven release arftifact urls?

    Thanks in advance for short feedback!

    Best regards,


  14. Unknown User (dtriphaus)


    ist it possible to get an RSS-Feed for releases via Hudson? There are RSS-Feeds from Hudson for failed builds and all builds, but i would like to have an RSS-Feed only for release-versions.

    Best regards,


  15. Unknown User (matt.pierce@colinx.com)

    I'm not actually using this plugin, but just running the maven-release-plugin by putting release:prepare and release:perform in the goals and options of my hudson build when I want to release.

    When I run a hudson build of a maven project using the release plugin, my primary artifact (the war file for the webapp I'm building) no longer gets saved as an artifact in hudson.  It does get created and deployed correctly to my releases repository.  If I run a regular build without releasing I get the war file as a hudson artifact.  If I add 'package' somewhere in the goals line with release:prepare and release:perform I get a war file artifact, but it is not the release version--it is either of the pre-release SNAPSHOT or the post-release SNAPSHOT (depending on where I put the package goal relative to the release goals).

    Is there a way to release and have the release-version war file available in Hudson as an artifact?  Will using this plugin accomplish that?

  16. Unknown User (bertrand gressier)

    This plugin is a good work !!

    Can you add a button to rollback the release (command : release:rollback) if the release is failed.
    you can detect if a rollback file exist in the workspace.

    today we must append a batch task to execute the command.


  17. Unknown User (coutemeier)

    Great plugin. It is working ok for me.
    But I miss integration with Sonar, a new option in Perform Maven release, something as:

    Sonar: Launch an analisys after release: [ ]

    If the check is on then will be launch a Sonar analisys, with the version generated (not the snapshot, the version release).
    And the configuration, in the line of de Sonar plugin for Hudson, no need in pom.xml.

  18. Unknown User (jwdani@yahoo.com)

    Is it possible to add parameterized functionality to the plug-in?  Parameters that can be set in Release Plugin at run time and be accessible in the build proper. 

    1. Unknown User (jsirex)

  19. Unknown User (lfischer)


    is it possible to access the resulting version values as parameter for the "Release goals and options" field?

    I need to specify a different SCM tag and would like to use something like this:

    -Dtag=myspecialvalue-${releaseVersion} -Dresume=false release:prepare release:perform

    This should result in a scm tag like "myspecialvalue-0.0.1"

    1. Unknown User (leif81)

      I believe you want the tagNameFormat option.


      However I'm having problems getting it to work when set from the command line. Examples show it being used in a pom.xml though.


  20. Unknown User (sellerjd)

    Is there a way to get this plugin to work with a build that is parametrized?  I've got a release build where we scp the artifact after the build to a server and location that is input by the user.



  21. Unknown User (kingmesal)

    I have used this plugin and the release plugin extensively and the simplicity in this plugin is great. However, it would be wonderful if this plugin could move just a step forward toward the release plugin where you can define a pre release build step, and a post release build step.  The downside to the release plugin is that it doesn't allow you to repurpose a job in as simple of a way as this plugin does for the sake of cutting releases.  That plugin forces the main build goals and options to be the release step... rather baffling if you ask me. Any chance of this happening?

  22. Unknown User (soumen_trivedi)

    This is a real nice plugin and it works like a charm. Although I would like to point out that there is a tiny mistake in the documentation for v 0.9.0 (especially for users of 1.424 LTS), this version does not work in 1.424 LTS, and works only with Jenkins version 1.442 or above. Took us some time to establish this, if you want to look yourself, refer to M2Release-0.9.0.pom file

    Thanks once again for this wonderful plugin and we look forward for updates compatible with LTS releases and documentation :P.

  23. Is it possible to add the "Perform Maven Release" action on job's modules ??

  24. Unknown User (jhack)

    It would be useful to have the possibility to rollback a release if something goes wrong.

  25. Unknown User (jsirex)

    Look like if I perform "Schedule Maven Release" in Chrome no goals are passed into build lifecycle: 

    Executing Maven:  -B -f c:\opt\Jenkins\jobs\project-ci\workspace\pom.xml -DdevelopmentVersion=4.4.005-SNAPSHOT -DreleaseVersion=4.4.004 -Dusername=user -Dpassword=*********
    No goals have been specified for this build. You must specify a valid lifecycle phase or a goal
    1. Unknown User (jsirex)

      This bug was related to " symbol in password

  26. Unknown User (yeposh)

    In gitHub Messages.java is missing for this plugin.. 

    Answered my Question: https://wiki.jenkins-ci.org/display/JENKINS/Internationalization

  27. Unknown User (andriusordojan)

    Is it possible to specify the version for each module individually? Currently it sets the versions globally meaning all of the modules will have the same version for the release.

    It seems in version 0.8.0 of the plugin the functionality was removed and the screenshots on the wiki are just outdated. Also I assume the field called "Default versioning mode" in the job configuration page is just left over markup from earlier versions since it doesn't affect the release processes and can't be changed. 

    Can someone confirm that I understand everything correctly? Also is it conclusive that implementing the capability to choose the versions for each module individually is not going to happen, because that is one piece of functionality that I am missing in this plugin. I might be able to implement this functionality myself if it is possible.

    1. Unknown User (narocroc)

      Yes I would also like this functionality to be added back in if possible. We often have modules which are at a different version to the main module in a multi-module project. Is there a reason that this functionality was removed?

  28. Unknown User (ha1)

    Are the Release Version and Development Version available as variables in the build? If so, what are the variable names? Might want to consider putting that in the documentation if there's a clear answer

  29. Unknown User (leif81)

    I hit an issue today where the Perform Maven Release was failing with no errors in the Jenkins build log. The dry run worked so I had a hunch it was related to the commits that get written as part of the release. When I shelled into my slave workspace I could see that Jenkins had created the "prepare" commit of the release; "[maven-release-plugin] prepare for next development iteration". But it was to "* (detached)" rather than the master branch as expected. To work around this I set the Git Plugin option "Local branch to use" to the master branch. See also http://stackoverflow.com/questions/3858563/active-git-branch-is-no-branch-on-hudson-ci

  30. Unknown User (tfnico)

    For anyone who wants to set up the M2 Release Plugin to use Jenkins SSH Credentials, I heartily recommend the SSH Agent Plugin.

    The problem is that M2 Release Plugin does not check for Jenkins Credentials, it just does a (in my case) git push with whatever SSH config/keys it finds on the slave performing the release. For me, having the credentials for Git/SSH stored centrally under Jenkins Credentials, this is a bit of a downer. But by setting up ssh-agent, the Maven release execution will pick up it up and push using the chosen credential. Really sweet. 

  31. Unknown User (billwonch)

    Hi - can you tell me if the release plugin is reachable through the REST API?  I'd like to be able to kick off a build remotely.