Preloader image
This document is aimed at guiding a release manager through the general release process. You will need either a Linux, Mac, or failing that a Linux Virtual (with at least a 50GB Drive) on Win.

Preparation of The Branch

Run menu:ant -f rat.xml[report.txt] on trunk to ensure all licences are in place.

  • Review the report.txt and update/add missing headers until clean.

  • Tip, search for Unapproved licenses: at the beginning of the report for a list.

Branch the version to release and ensure it builds and passes all tests.

Add a buildbot CI setup for branch here:

Basically search for the following line and it should be obvious how to add a new builder:

c['builders'].append(tomee_hemera_builder("tomee-trunk-ubuntu", "tomee/tomee/trunk"))

An SVN trigger must be added afterwards. This can only be done by someone with admin permissions, such as any PMC chair or an Infra team member. Just drop an email to

Create a TCK Branch

Branch the TCK using the same version as the release branch from here:

Update the TCK branch files to point to the version branch.


Run menu:ant -f rat.xml[report.txt] on the branch.

  • Review the report.txt and update/add missing headers until clean.

  • Tip, search for Unapproved licenses:.

Check SVN Authentication

Pre-authenticate svn repositories to ensure your credentials are cached before using any tools.

svn mkdir --username [apacheuser] --password [apachepw] -m "Create test dir"
svn delete --username [apacheuser] --password [apachepw] -m "Delete test dir"
svn mkdir --username [apacheuser] --password [apachepw] -m "Create test dir"
svn delete --username [apacheuser] --password [apachepw] -m "Delete test dir"
svn mkdir --username [apacheuser] --password [apachepw] -m "Create test dir"
svn delete --username [apacheuser] --password [apachepw] -m "Delete test dir"

Prepare Maven Authentication

Ensure your maven .m2/settings.xml correct, and be aware that the tools currently require a clear text password:





Code Signing Setup

If this is your first release then you will have to ensure that you have a code signing key prepared on the machine from which you perform the release. The process is quite intense. You can find information here:

However, the basic steps are:

  • Create a key using gpg --gen-key, using size 4096 and answering the questions that command issues.

  • During the process you will have to generate random entropy, this is best achieved in another console and issuing the command find / > /dev/null and waiting a minute.

  • List the keys using gpg --list-keys and take note of the name

Once you have your key then you will need to append it to the key file here:

That is best done as the file itself explains, once you open and view it in a UTF-8 safe text editor you will see the description at the top. + Just follow the instructions there on how to append your key. The basic steps are also here, please read both before you proceed:

  • Save the KEYS file on your local machine and import it using gpg --import KEYS

  • Then create the new KEYS file using (gpg --list-sigs && gpg --armor --export ) >> KEYS

  • Check that the new KEYS file contains your key.

  • Log in to and locate /dist/tomee/KEYS

  • Make a backup of the remote KEYS file just in case

  • Overwrite the old /dist/tomee/KEYS file with your new one that now also contains your key.

  • Go to and add your ascii armoured key

  • Take note of your key fingerprint using gpg --fingerprint

  • Go to, log in and fill OpenPGP Public Key Primary Fingerprint: with the value of your fingerprint.

Build the Release Tools

Checkout the release tools using SVN from here

Really read the README.mdtext and follow the instructions for building the 3rd party libraries. + Basically SVN checkout and compile Swizzle and Tentacles

Build the release tools, mvn clean install -DskipTests -DfailIfNoTests=false

Have a look at to see the entry point.

Understand that the release tools are not polished, and you currently may have to edit source and re-compile.

Site Staging For some of the release steps you will need to provide documentation on the site.

Checkout the site here:

Most of the content can be found under 'content' and subdirectories.

When you commit changes the site should be built automatically by the buildbot, but you can force a build on IRC using:

**tomee-bot: force build tomee-site-staging**

The buildbot staging result can be seen here:

And the actual staging site, where you can review your changes, is here:

Once you are happy with the staging you can publish to the real site using:

Begin The Release Process

Ensure TCK is passing all tests, and if so create an SVN tag from the branch.

Note: It is a future goal to either separate OpenEJB from TomEE or unify the versions so the
[maven-release-plugin]( can be used.

Because we cannot use the Maven release tools we currently have to create a an SVN tag manually. The best way to do this is to:

 - Copy the branch to a staging branch using:
   > svn copy[version][version]-staging -m "Staging [version]"
 - Checkout the staging branch using:
   > svn co[version]-staging tomee-[version]-staging
 - Update all SNAPSHOT versions to the release versions in the local tomee-[version]-staging and commit.
 - Create the tag from the staging:
   > svn copy[version]-staging[version] -m "Tag [version]"
 - Delete the staging branch using:
   > svn rm[version]-staging -m "Delete staging"

Open a console on the release-tools directory.

Before running any ./ activity always check the release tools code for the command tomee-release-tools/src/main/java/org/apache/openejb/tools/release/cmd. At the moment some of the commands need manually editing to work. Eventually the commands should be re-written.

All JIRA actions should be performed on the ASF JIRA here:

Ensure JIRAs have been filed for commits using ./ reviewcommits

Update fixVersions for JIRAs used in SVN commits using ./ updatejiras - Untested, requires investigation

Review and bulk Close all JIRAs for the version to be released.

Publish the changed binaries report (if any) using ./ comparelibraries

Write and publish the release notes preview on the staging site.

Publish a summary of the RAT report preview on the staging site.

Using the RAT report as a guide update LICENSE and NOTICE files for any changed binaries, and add new ones if required.

Update branch versions. How you do this is up to you at this point in time.

Update trunk versions. How you do this is up to you at this point in time.

Create the next version iterations in JIRA.

Rolling Out The Preview

Note: Before running anything below ensure you either have:

 - A valid from the last release in your home directory (Speak to the last release manager).
 - Or have modified **tomee-release-tools/src/main/java/org/apache/openejb/tools/release/** with current versions and **mvn clean install**.

Ensure the TCK passes with preview repositories by editing and ensuring paths are correct in the following files:


Publish the preview using ./ roll binaries legal releasenotes preview - You can run these tasks like so, or individually in order. It will be likely that this will have to be repeated several times before a successful vote.

The legal step will create the legal report files in the /tmp/download/staging-[revision]/legal directory. These need to be added to the staging repo.

  • Delete the [legal]/repo and [legal]/content directories, as these are no longer required rm -R /tmp/download/staging-[revision]/legal/content rm -R /tmp/download/staging-[revision]/legal/repo

  • Perform a non-recursive checkout of the staging repo and add the legal: svn co -N revision /tmp/download/staging mv /tmp/download/staging-[revision]/legal /tmp/download/staging cd /tmp/download/staging-[revision] svn add legal

Once the binaries are in place add the staging repository to the corresponding TCK project and fire off a build. To fire off a build on EC2 from the TCK directory speak to the last release manager for the curl command to use

If the TCK fails then discuss, fix and re-roll.

Publish a Vote if, and only if, the TCK passes.

Votes are generally managed and identified using keywords such as [VOTE], [CANCELLED] and [RESULT]

If the vote fails then discuss, fix and re-roll.

Voted Binaries

Once the vote has passed then release the binaries on Nexus:

Update both OpenEJB and TomEE JIRA versions as released (Set the release date).

Copy the binaries to the release location (User rights require a PMC to do this)


Wait for the binaries to replicate to mirrors. Here is a neat script from David to check the status:


RELEASE=${1?Specify a release, such as './ tomee-1.7.1'}

function list_mirrors {
    wget -q -O - $DYN | tr '">< ' '\n' | grep "^http.*$RELEASE/" | sort | uniq

function status_code {
    wget -v "$1" 2>&1| grep 'awaiting response' | tr ' ' '\n' | grep "[0-9]"

list_mirrors | while read n; do
    echo "$(status_code $n) $n"
done | sort | grep 'http'

Commit and publish changes to the site, see Site Staging