Maven Deployment

General instructions for Maven deployment can be found here.

Preparation

Gnome users with gnupg2 > 2.1 will have to add the following code snippet to their .bashrc in order to avoid re-entering the gpg password multiple times when signing the release artifacts.

# entries required by gpg-agent
# see http://manpages.ubuntu.com/manpages/xenial/man1/gpg-agent.1.html
# see https://bugzilla.redhat.com/show_bug.cgi?id=1221234
function gpg-update() {
    GPG_TTY=$(tty)
    GPG_PID=$(pidof gpg-agent)
    GPG_AGENT_INFO=${HOME}/.gnupg/S.gpg-agent:$GPG_PID:1
    export GPG_TTY
    export GPG_AGENT_INFO
}

gpg-update

If you see the following message:

Enter passphrase: can't connect to `/home/alexander/.gnupg/S.gpg-agent': No such file or directory

verify that your gpg-agent is running. If not, start with as follows

eval $(gpg-agent --daemon)

Release Workflow

Assuming the following variables

export DEV_VER="1.1-SNAPSHOT" # development version
export REL_VER="1.1.1"        # next release version

Step 1. Bump up the project version.

mvn clean
mvn versions:set -DnewVersion=$REL_VER
find -name pom.xml | xargs sed -i "s|<peel.version>$DEV_VER<\/peel.version>|<peel.version>$REL_VER<\/peel.version>|g"
sed -i "s|current_version:    .*|current_version:    $REL_VER|g" docs/_config.yml
git commit -am "Bumping up the project version to v$REL_VER."

Step 2. Tag the release.

git tag "v$REL_VER"

Step 3. Deploy the release to Sonatype.

First, clean and deploy to Sonatype using the release profile.

mvn clean deploy -P release

At the end of the run, you will see a line looking as follows:

[INFO]  * Closing staging repository with ID "orgpeelframework-1234".

Other people can test the repository after adding the following code snippet to their ~/.m2/settings.xml:

<profiles>
  <profile>
    <id>peel-staging</id>
    <activation><activeByDefault>true</activeByDefault></activation>
    <repositories>
      <repository>
        <id>peel-staging</id>
        <url>https://oss.sonatype.org/content/repositories/orgpeelframework-1234</url>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>false</enabled></snapshots>
      </repository>
    </repositories>
  </profile>
</profiles>

Upon inspecting the staged repository, you have either verified that everything is fine and can proceed with releasing it, or you have found a problem and want to drop it. To do this from the command line, execute

# to release the staged repository (after validating that it works)
mvn nexus-staging:release -DstagingRepositoryId=orgpeelframework-1234 
# to drop the staged repository (e.g., if you found an issue)
mvn nexus-staging:drop -DstagingRepositoryId=orgpeelframework-1234 

Alternatively, login to the Sonatype Repository Manager and open the the "Staging Repositories" tab. You should see an orgpeelframework staging repository containing the deployed release. Select the repository and click the release action from the menu in the top pane.

Check the official "Deployment Releasing" documentation from Sonatype for a step-by-step description with screenshots.

For Step 6, it makes sense to save the peel-empty-bundle-$REL_VER.tar.gz build artifact on the side.

find -type f -name "peel-empty-bundle-$REL_VER.tar.gz" | xargs -I{} cp {} ~/Downloads/.

Step 4. Revert the development version.

mvn clean
mvn versions:revert
find -name pom.xml | xargs sed -i "s|<peel.version>$REL_VER<\/peel.version>|<peel.version>$DEV_VER<\/peel.version>|g"
git commit -am "Reverting the project version to $DEV_VER."

Step 5. Push the new commits online.

git push upstream master --tags

Attach the ~/Downloads/peel-empty-bundle-$REL_VER.tar.gz build artifact to the release.