guhilling / smart-release-plugin

A maven release plugin for automatically releasing only updated modules of multi-module maven projects

Documentation, download, and usage instructions

Automatically releases only changed modules of a multi-module maven project.

Full documentation is available here as maven site documentation.

The project was started as a fork of Daniel Flowers multi-module-maven-release-plugin with with the goal to create bugfix releases automatically (See documentation).

Features

• Automatically releases only changed modules of a multi-module maven project.
  • Dependencies are automatically resolved transitively.
  • Version numbers must follow format -SNAPSHOT.
  • Minor and bugfix numbers are chosen automatically.
  • Regular releases increase the minor number in the resulting artifacts.
  • Bugfix releases increase the bugfix number relative to the latest regular release.
• Allows to create bugfix-releases in bugfix branches.
  • Use flag -DperformBugfixRelease to trigger bugfix.
• Tracks the released versions robust and efficient in release-files.
• The actual release creation is up to the user (See [Quick start]).

Quick Start

Most important: You have to use git as version control system. Support for other VCS is not yet planned.

Configuration of the plugin

Add the plugin to your pom:

    <build>
        <plugins>
            <plugin>
                <groupId>de.hilling.maven.release</groupId>
                <artifactId>smart-release-plugin</artifactId>
                <version>4.0</version>
            </plugin>
        </plugins>
    </build>

Release

To run the release, use mvn smart-release:prepare. This will execute the following steps:

• Sanity checks:
  • Local Repository clean?
  • Version numbers follow the required scheme?
  • No SNAPSHOT-dependencies except the local ones?
• Version management:
  • All changes relative to the latest tag are computed. The latest tag is stored in the release-info.json file. If this file is missing the plugin assumes that all modules are released for the first time.
  • All modules that have changes relative to their latest release (that is stored in release-info.json) are prepared for release by setting their minor number to the next minor release number in their pom.xml. The same is done for all modules that have transitive dependencies on these modules. The plugin prints out which modules will be released and why. The release-info.json file is commited an tagged. It is not pushed. It is up to you, when you want to push the file and the corresponding tag.
  • All modules that are not released will not be changed.
• A list of modules to build is stored in modules-to-build.txt. The content can be fed directly to the maven -pl (project list) option
• A list of files that need to be reverted later is stored in files-to-revert.txt. The cleanup goal can be used to actual revert.
• You do a maven run to build an deploy the modules that have changed. Usually you would run:

   mvn -pl $(cat modules-to-build.txt) clean deploy

• If the deploy-stage was successful you should push the updated release-info.json and the corresponding tag:
  • This should actually be performed automatically by jenkins or whatever ci-System you are using to perform your releases. You are using a ci-System, aren't you?.
  • Of course the details of the git setup are up to you. It is actually one of the advantages of this plugin that it only does one thing and lets you configure how to handle the rest.

   git push && git push --tags

smart-release-plugin's Issues

changes in submodule aggregator/parents are ignored

Change builds to two phases

A release build should be more transparent, so I'd like to use the following plan:

• Determine versions to be released (algorithm and implementation is the same as before).
• Change the project version to the determined versions (step 1). This could later also be done using the versions-plugin (more robust?).
• Create a list of modules to be built. This list is stored on disk to be used in the next steps.
• Do a release-build and deployment using whatever is necessary (e.g. mvn clean deploy).
• Do commits as you like it (at least release-info.json)
• Rollback all changes made in the second step.

plugin ignores snapshot dependency

An aggregator contains modules A and B. A depends on B-<major.minor>-SNAPSHOT, which is in the repository due to some previous build.

For the smart release plugin, both A and B version patterns are updated to <major>-SNAPSHOT, but the dependency in A's pom was overlooked and still has the <major.minor>-SNAPSHOT pattern.

The sanity check ignores the snapshot dependency.