As I've mentioned in previous blogs (Maven Release Woes with Flat Project Structures and Maven Release with Flat Structures Revisited), the support for custom SCM structures is spotty in the release plugin. It is highly desirable to leverage the release plugin as it provides a lot of functionality we do not want to have to duplicate. By using profiles and activations, we can still leverage the release plugin with only marginal manual intervention.
First let's review what functionality the release plugin provides:
- Check that there are no uncommitted changes in the sources
- Check that there are no SNAPSHOT dependencies
- Change the version in the poms from
x-SNAPSHOTto a new version (you will be prompted for the versions to use)
- Transform the SCM information in the POM to include the final destination of the tag
- Run the project tests against the modified POMs to confirm everything is in working order
- Commit the modified POMs
- Tag the code in the SCM with a version name (this will be prompted for)
- Bump the version in the POMs to a new value
y-SNAPSHOT(these values will also be prompted for)
- Commit the modified POMs
- Checkout from an SCM URL with optional tag
- Run the predefined Maven goals to release the project (by default, deploy site-deploy)
That's a lot of functionality we don't want to reproduce manually. Provided your aggregator and modules are setup in the "flat structure" I've used for demonstration purposes in the previous two blogs, you're in luck.
We're in a bit of catch-22 here when the aggregator is also used for inheritence. Our modules need the aggregator/parent to be deployed before they can be released. However, our aggregator/parent identifies all the modules to be released which ultimately fail because the release plugin doesn't support our SCM structures! I recommend placing the modules declaration into a profile that can be activated by your CI server or developers when necessary. This will allow the user to release each module of the multi-module build individually. This will require the releaser to know the order of release to perform this correctly.
<>> <>> <>>modules> <>> <>> <>>BUILD_NUMBER> > > <>> <>>../release-module1> <>>../release-module2> > > >
Here I use a property for activation named
BUILD_NUMBER as this is a property Hudson supplies to all Maven builds.
There are some minor things that must be done manually to get all this to work, but this solution is better than the alternative (nothing). Once the modules declaration is located inside a non-activated profile, here are the steps to perform a release for your mutli-module build.
- Open all modules of the multi-module build and change the parent version from
*-SNAPSHOTto the released version and check in those poms. (easy with an IDE or sed/awk).
- Release each module individually, in the order the reactor would perform a release.
- Open all modules of the multi-module build and change the parent version from the released version to the new
There is also a small byproduct of the release process that might be a bug with the release plugin, I'm not sure. If you've structured your projects like mine, the module of a multi-module build do not specify versions allowing the inheritance mechanism to supply that metadata. Once released, the release plugin will update your POM with a version element, something that was not present before. You'll need to also manually remove these.
For example, before release:
<>> <>>release-parent> <>>com.captechventures> <>>0.0.12> <>>../release-parent/pom.xml> > <>>4.0.0> <>>com.captechventures> <>>release-module2>
<>> <>>release-parent> <>>com.captechventures> <>>0.0.12> <>>../release-parent/pom.xml> > <>>4.0.0> <>>com.captechventures> <>>release-module2> <>>0.0.13-SNAPSHOT>
I'm sure a small global replace, similar to the one we used to change the parent pom version, would work to remove this unnecessary entry.