|author||Lee Rhodes <firstname.lastname@example.org>||Wed Aug 12 13:50:00 2015 -0700|
|committer||Lee Rhodes <email@example.com>||Wed Aug 12 13:50:00 2015 -0700|
[maven-release-plugin] prepare release sketches-core-0.1.1
Core Sketch Library
Use Apache Maven 3.0 to build this project
mvn clean install
mvn -P release-profile clean install
First, “prepare” a release. Preparing a release ensures you have no checked out file and no SNAPSHOT dependencies. It changes the version in all pom.xml files to the release version. It then runs all the tests. If everything passes, the release version is committed to the SCM system and tagged. The version number is then updated in all the pom.xml files again, this time to the next development version. Finally, the changes are commited again to the SCM repository.
Next, “perform” a release. Performing a release checks out the tagged release from the SCM system into a new directory, builds it, and then runs the configured deploy goals to publish the release to a maven repository (Maven central). Performing a release automatically enables the
release-profile in maven, causing source and javadoc jars to be automatically created and published.
You can add the ‘-DdryRun=true’ option to test the release process without actually generating a release. dryRun is supported on both the prepare and perform steps.
If a release has been prepared but not performed yet, the release can be rolled back. Rolling back a release resets the pom.xml version numbers and tags in the SCM system, effectively nullifying the release.
A release cannot be rolled back if it has already been cleaned up (the release.properties file and other metadata removed).
If a release fails to prepare or crashs, it can leave various files behind. These can be cleaned up with a release clean.
The internal Memory package detects whether the methods unique to the Unsafe class in JDK8 are present; if not, methods that are compatible with JDK7 are substituted using an internal interface. In order for this to work, this library still needs to be compiled using jdk8 but it should be done with both source and target versions of jdk7 specified in pom.xml. The resultant jar will work on jdk7 and jdk8.