TLDR; The versions 2.0.1 to 2.0.11 of spt-development-cid are identical to 2.0.0 and therefore there is no pressing need to upgrade.
In an effort to stream line the release process of the spt-development-cid (and ultimately the other related projects) I managed to burn through 11 patch release numbers, without actually making any code changes. I have therefore removed all but the 2.0.11 release from Github and would also remove them from Maven Central if I were able to.
Just to reiterate, there is nothing wrong with versions 2.0.1 to 2.0.11 other than they contain no changes when compared to version 2.0.0.
Below is a summary of some of the problems I ran into whilst trying to automate the release process with Travis CI and the solutions I found.
maven-release-plugin requires full clone of repository
mvn release:prepare release:perform -B will update the versions and kick off the Maven
deploy phase - I already had
the relevant plugins configured to deploy to sonatype with
mvn deploy -Prelease. Out of the box, Travis performs
a shallow clone of the current branch, it was therefore necessary to switch off the default checkout and issue the
clone and checkout commands manually.
The other commands in the install phase are used to capture the version number for releasing to Github and decrypting the private key used for signing the jars uploaded to Sonatype.
Deploy stage requires values from maven
Add encrypted environment variables and reference them in a custom settings file referenced with the
Inability to encrypt special characters in environment variables properly
cd to a clone of the repository and use the following command, entering
ENV_VAR=value when prompted:
Prevent checkins by
maven-release-plugin kicking off another build (and release)
scmCommentPrefix setting of
maven-release-plugin to include
Note also the
goals configuration setting with the value
deploy. If a distribution site is provided in the pom, the
maven-release-plugin will run the
site-deploy phase which will attempt to upload the release to the site specified.
To upload to Github, we need to use the releases provider; specifying
deploy runs the
deploy phase instead.
Create the release in Github
The Travis Github releases provider makes this straight forward,
however it is tightly coupled to tagging a particular version of the code. In order to prevent an infinite loop of
releases all of the
maven-release-plugin checkins include the
[skip travis] comment, which stops Travis from
running the build for those checkins - including the ‘tag build’. To resolve this, rather than specifying on
I have specified
branch: main so the releases provider runs when there is a checkin on the main
branch (after the
maven-release-plugin has run and tagged the build). For this to work, the
variable needs to be set.