jmock-packaging
Maven packaging for JMock
Release Overview
JMock is organised into two modules, jmock-library and jmock-packaging (this project). The main module is responsible for building deployment artifacts. The packaging project is just responsible for collecting these, packaging them (and creating pom
s) and publishing to a Maven repository. It doesn't actually "build" any source or execute any tests.
The general process for deploying new versions is
- Tag release version in Subversion
- Run the
release.sh
script from jmock-library, it will export the tag from Subversion, build it (using thebuild.xml
Ant script) and SCP artifacts to a remote location (www.jmock.org:/home/jmock/public_dist) - You need to somehow make these artifacts available at
http://jmock.org/downloads
(subsequent packaging steps require this). - Package and publish the artifacts created above using this project.
Terminology
Just so that we're all talking the same language, some definitions of terms we use when talking about releasing.
- build : building a set of binary artifacts (.jar, javadoc etc) for deployment
- release : tagging a baseline in source control.
- deploy : distributing the build artifacts to the internet
- packaging : specifically referring to creating the Maven packages for subsequent deployment (upload) to Maven central
- publishing : Maven equivalent of deploy; distribute the build artifacts to Maven central (indirectly)
Currently, build and release are the responsibility of the jmock-library
project. The deploy step is currently done by the jmock-library
to make artifacts available for manual download via jmock.org
. The packaging and publishing steps are the responsibility of the jmock-packaging
project.
Packaging and Publishing Procedure
Prerequisites
Because the source projects aren't part of this packaging project, the source has to be retrieved before we can package it. Currently, this is done by an embedded Groovy script which attempts to download artifacts as part of the Maven build. It attempts to download artifacts from http://jmock.org/downloads. It seems to be platform specific as it has problems on Windows.
When it executes, it runs the src/script/download-jars.sh
script, with options making it equivalent to
./download-jars.sh http://jmock.org/downloads jmock-2.6.0-jars.zip target jmock-2.6.0
Make sure you change the following line in the jmock2
profile of the parent pom.xml
to reflect the release.
<release.version>2.6.0</release.version>
Maven Profiles
The parent pom supports two profiles; jmock1
and jmock2
. The profile determines which artifacts are part of the release.
Local Snapshot Build
mvn -Pjmock2 install
where jmock2
in the profile name, it can be either jmock1
or jmock2
.
Publish Snapshot to OSS Sonatype
Make sure the pom.xml
version should -SNAPSHOT
.
mvn -Pjmock2 clean deploy
(and verify in the Snapshot repository)
Release
Perform a sanity check
mvn -Pjmock2 release:prepare -DdryRun=true
If it looks good, clean up after yourself
mvn -Pjmock2 release:clean
rm *.log
Then move onto the release proper
mvn -Pjmock2 release:prepare
The maven release plugin will interactively ask to replace the snapshot version with the appropriate version and create an SCM tag with the snapshots resolved.
mvn -Pjmock2 release:perform
Distribution Management
We're using OSS Sonatype as the target for deployment, it should periodically get picked up by Maven Central.
We're no longer using Codehaus and the nasty Wagon/WebDAV nonsense.
Signing Artifacts
The JMock Devlopers ([email protected]) public key hash is 6DDC9D8B
. It's been distributed to public key servers, so people can import using the following command.
$ gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 6DDC9D8B
The maven-gpg-plugin
will attempt to sign all artifacts before uploading to OSS Sonatype. Artifacts must be signed before Maven central will accept them. You'll need to ask around for the private key and pass phrase and install GPG tools on the machine you'll be deploying from.