Please see https://github.com/BioPAX/Paxtools (this page, despite having just been updated, will be removed in the future.)
The following instructions are only for those developers who are responsible for making an official public Paxtools release or setting up own continuous integration system (e.g., Jenkins). Others can simply download the latest paxtools release from  or checkout a particular version of the source code at  to build it locally with "mvn clean package" command.
Checking out the latest source code
git clone https://github.com/BioPAX/Paxtools
Deploying snapshots to the OSSRH Maven repository
mvn clean deploy
See: http://central.sonatype.org/pages/apache-maven.html#performing-a-release-deployment (Remark: in the Paxtools' parent pom.xml, the release maven profile is called "sonatype-release".)
When it is time to make a new release, we should follow the check-list below in order to get everything right. We use GitHub flow (or simple "feature branch") branching model. Normally, mainstream development goes in the master branch of this project. Releases and quick-fixes are made in separate temporary feature branches and then merged back to the master, and deleted.
Here is how to release manually, not using maven-release-plugin (but if you want it with maven-release-plugin, remember to clone and build your release version locally - after executing release:prepare and before release:perform, or it fails otherwise...)
Start a new branch (if something went wrong, and you did not push to the remote repository, you's simply either fix or delete your local sources and start over), e.g., release-X.Y.Z:
git checkout -b release-X.Y.Z
Bump the version number - current release:
mvn versions:set -DnewVersion=X.Y.Z git commit -m "For the release, updated project version to X.Y.Z" git tag -a vX.Y.Z -m "Release X.Y.Z"
(Ok to push, with --tags, to the remote repository if you're 100500% sure there's nothing more to fix in this version.)
Let's create the distribution vX.Y.Z:
mvn clean deploy -P sonatype-release
This should automatically create the documentation, Java API-DOC and the source JARs, and push them to the Nexus server.
Deploying the maven-generated site: stage, add to the staged site folder to the 'gh-pages' branch, commit/push there (TODO...).
mvn site site:stage -DstagingDirectory=/path/to/paxtools-gh-pages/X.Y.Z
Creating "fat" JARs (with dependencies) for distribution. For non-Mavenized projects, it is more convenient to distribute a single executable JAR file of the library with all dependency included.
cd paxtools-console mvn clean install
This creates target/paxtools.jar. By default, this JAR package does not include the Jena IO module, but you also have the option (using the "jena" profile) to include it in the package:
mvn install -Pjena
Now that you have the JAR file, you can rename it (for the default one, don't forget to put no-jena appendix, e.g. paxtools-X.Y.Z.jar for the one with the Jena IO and paxtools-X.Y.Z-no-jena.jar for the default one) and put it under /home/frs/project/b/bi/biopax/paxtools folder on SourceForge for it to be listed under the tab, Files . For more file transferring options, you can have a look at the SF help page on this .
Bump the version - next development iteration:
mvn versions:set -DnewVersion=X'.Y'.Z'-SNAPSHOT git commit -m "Updated project version to next X'.Y'.Z'-SNAPSHOT"
Once the release, site, distribution are done, it it time to merge the changes back to the master branch.
git checkout master git merge release-X.Y.Z git branch -d release-X.Y.Z git push --tags
Releasing to Central Maven