Maven packaging for JMock
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
poms) 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.shscript from jmock-library, it will export the tag from Subversion, build it (using the
build.xmlAnt 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.
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
Packaging and Publishing Procedure
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.
The parent pom supports two profiles;
jmock2. The profile determines which artifacts are part of the release.
Local Snapshot Build
mvn -Pjmock2 install
jmock2 in the profile name, it can be either
Publish Snapshot to OSS Sonatype
Make sure the
pom.xml version should
mvn -Pjmock2 clean deploy
(and verify in the Snapshot repository)
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
We're no longer using Codehaus and the nasty Wagon/WebDAV nonsense.
The JMock Devlopers (firstname.lastname@example.org) 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
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.