This is a Maven plugin that allows for promoting the artifacts of the previous snapshot build to a release. This allows you to speed up the release process, by avoiding running the same compile-test-package phases again, when you already have a good build.

This plugin circumvents some of the precautions and conventions of Maven, and hopefully that is exactly what you aimed to when you found this plugin.

Add this to your pom.xml:

  <build>
    <plugins>
      <plugin>
        <groupId>se.jiderhamn</groupId>
        <artifactId>promote-maven-plugin</artifactId>
        <version>2.0.0</version>
        <!-- Automatically execute promote:make-promotable after each snapshot build -->
        <executions>
          <execution>
            <goals>
              <goal>make-promotable</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Build your snapshot as usual, say

mvn clean package

Now, in case you want to promote the snapshot into a release you would run

mvn promote:prepare release:prepare

In case you prefer, you could instead add the following to the <configuration> of the maven-release-plugin

<preparationGoals>promote:artifacts deploy:deploy</preparationGoals>

and then to release run

mvn release:prepare

Note that release:perform should not be invoked. For that reason, you may also want to add release:clean.

2.0.0 is a minor change compared to 1.1.0, but since the change to <preparationGoals> could break existing configurations, the major version is bumped. If you have added <preparationGoals> to your pom.xml you need to update according to the Usage section above.

You will likely want to use this plugin together with Continuous Integration, so that the latest code is always built, and as soon as you are ready to release you'll just promote the last build.

For Jenkins, it is recommended to combine this Maven plugin with the Promoted Builds Jenkins plugin.

Configure a normal Maven Jenkins project, and set Build / Goals and options as usual, say clean install. (This assumes you've configured promote:make-promotable to be executed automatically as of above.)

Create a manually triggered promotion (Promote builds when... + Only when manually approved) and select a Name and an Icon. (Unfortunately, the Name cannot currently contain any variables, which would have allowed hoovering the icon/badge to see the released version. Please vote for JENKINS-31725!)

Use Add Parameter to add 2 String Parameter s, one named releaseVersion and another named developmentVersion (as per the release:prepare goal of the Maven Release Plugin).

Add action: Invoke top-level Maven targets and set Goals to release:clean promote:prepare release:prepare.

Now it will be possible to manually promote the latest -SNAPSHOT build, allowing you to set the version of the release and the SNAPSHOT version of the next development iteration, just like you would with a normal Maven release.

These are the Maven goals defined by this plugin

• promote:make-promotable Identifies the artifacts of the build, and writes them to promotable-artifacts.properties in the project directory. This should be invoked at the end of any snapshot build that are candidates for promotion.
• promote:prepare Configures the preparationGoals to perform the release by invoking promote:artifacts + deploy:deploy
• promote:artifacts Read the artifact list written by promote:make-promotable during the snapshot build and register them as being the artifacts produced by the current build.
• promote:no-op Does nothing (no operation); used as dummy goal to avoid default goals.

You should be aware that in case you have a multi module Maven project with "nested" packaging, i.e. one of your modules produces a WAR (<packaging>war</packaging>) that contains JARs produced by other modules in the same project, then the name of those .jars inside the promoted .war will be the -SNAPSHOT that was promoted.

Example: You have a Maven multi module project that creates foo-[VERSION].jar which is included in bar-[VERSION].war. When promote the SNAPSHOT build 1.2.3-SNAPSHOT to a 1.2.3 release, then bar-1.2.3.war will contain foo-1.2.3-SNAPSHOT.jar.

If this is a problem, then this plugin is not for you.

Even though it would have been theoretically possible for the plugin to rename the JAR inside the WAR that would defeat the purpose of the plugin. Unless we promote the exact same (binary) artifacts, it is per definition not a promotion but some kind of new build, and then you may as well use the ordinary Maven Release Plugin.