Skip to end of metadata
Go to start of metadata

Please read the Developer Infrastructure Information if you haven't yet before you proceed.

Table of Contents

Building MINA

You need Subversion to check out the source code from our source code repository, and Maven 2.2.1 to build the source code (Building with Maven 3.0 will also work). The following example shows how to build the current stable branch (2.0.4).

$ svn co mina
$ cd mina
$ mvn -Pserial clean install             # Build packages (JARs) for the core API and other extensions and install them to the local Maven repository.
$ mvn -Pserial site                      # Generate reports (JavaDoc and JXR)
$ mvn -Pserial package assembly:assembly # Generate a tarball (package goal needed to fix an assembly plugin bug)
$ mvn -Pserial eclipse:eclipse           # Generate Eclipse project files if you want

Eclipse users:
Don't forget to declare a classpath variable named M2_REPO, pointing to ~/.m2/repository, otherwise many links to existing jars will be broken.
You can declare new variables in Eclipse in Windows -> Preferences... and selecting Java -> Build Path -> Classpath Variables

There are also other branches that might interest you:

If you want to check out the source code of previous releases, you could try:

Coding Convention

We follow Sun's standard Java coding convention except that we always use spaces instead of tabs. Please download the Eclipse Java formatter settings file before you make any changes to the code.

This file is also available in the /resources directory.

Class header

As class header we use :

 * Class desciption here.
 * @author <a href="">Apache MINA Project</a>

The headers revisions tags are removed.

Working with Multiple Branches in One Eclipse Workspace

Just running mvn -Pserial eclipse:eclipse won't allow you to import MINA projects from more than one branches into one Eclipse workspace. You have to rename all project names in the generated .project and .classpath files to do that. Maven Eclipse plugin should provide an option that appends the version number to the project name, but this issue is not being resolved yet. Until this issue is resolved, please put the attached shell script files (mvnroot and mvn-eclipse) to your local path (e.g. /usr/local/bin) and run mvn-eclipse.

$ svn co mina
$ cd mina/tags/2.0.0
$ mvn-eclipse
$ cd ../2.0.1
$ mvn-eclipse
$ cd ../../trunk
$ mvn-eclipse

Then mvn eclipse:eclipse command is executed internally, and the branch name will be appended to all sub-module project files generated by Maven Eclipse plugin.

Deploying Snapshots (Commiters Only)

Before running Maven to deploy artifacts, please make sure if your umask is configured correctly. Unless configured properly, other committers will experience annoying 'permission denied' errors. If your default shell is bash, please update your umask setting in the ~/.bashrc file (create one if it doesn't exist.) by adding the following line:

umask 002

Please note that you have to edit the correct shrc file. If you use csh, then you will have to edit ~/.cshrc file.

Now you are ready to deploy the artifacts if you configured your umask correctly.

$ svn co mina
$ cd mina
$ mvn -Pserial clean deploy site site:deploy    # Make sure to run 'clean' goal first to prevent side effects from your IDE.

Please double-check the mode (i.e. 0664 or -rw-rw-r--, a.k.a permission code) of the deployed artifacts, otherwise you can waste other people's time significantly.

Releasing a Point Release (Committers Only)

Preparing the release for the vote

Before starting be sure to have the java and mvn command in your PATH.
On linux you can check with the following commands :

$ type mvn
mvn is hashed (/opt/maven-2.2.1/bin/mvn)
$ type java
java is hashed (/usr/bin/java)

Step 0: Building MINA

As weird as it sounds, for some unknown reason (most certainly a misconfiguration in the Maven poms), we can't just run the release without having previously build all the projects. This is done with the following command :

$ mvn clean install -Pserial

Step 1: Tagging and Deploying

First you need to configure maven for using the good username for scp and operation.

In the ~/.m2/settings.xml you need the following lines :

<settings xmlns=""

    <!-- To publish a snapshot of some part of Maven -->
      <password>-----Your password here-----</password>
    <!-- To publish a website of some part of Maven -->
    <!-- To stage a release of some part of Maven -->
      <password>-----Your password here-----</password>
    <!-- To stage a website of some part of Maven -->
      <id>stagingSite</id> <!-- must match hard-coded repository identifier in site:stage-deploy -->

        <!-- Configuration for artifacts signature -->
        <gpg.passphrase>-----Your passphrase here-----</gpg.passphrase>


step 2 : Processing with a dry run

After having checked out the trunk, and built it (see step 0),

$ svn co mina
$ cd mina
$ mvn clean install -Pserial

run the following commands :

$ mvn -Pserial,apache-release -DdryRun=true release:prepare    # Dry-run first.

Answer to maven questions :

"What is the release version for "Apache MINA"? (org.apache.mina:mina-parent) 2.0.0-<version>: :" <either use the default version as suggested, or type in the version you'd like to be used>

Warning !

Just after the last module, maven will ask you about the SCM tag :

What is SCM release tag or label for "Apache MINA"? (org.apache.mina:mina-parent) mina-parent-2.0.0: : 2.0.0

Do not type <enter> to select the default value. Instead, type the correct version.

Then some other questions will be asked, about the next version to use. The default values should be fine.

Be Careful

Make sure the change made by the release plugin is correct! (pom.xml, tags created)

Step 3 : Processing with the real release

When the dry run is successful, then you can do in real with the following commands:

$ mvn -Pserial,apache-release release:clean      # Clean up the temporary files created by the dry-run.
$ mvn -Pserial,apache-release release:prepare    # Copy to tags directory.

The first step will clean up the local sources, the second step will release for real. The same questions will be asked as those we had during the dry run step.

At some point, it will ask for your passphrase (the one you used when you created your PGP key). Type it in.

At the end, if you proceed the release on a Mac, you may get the following message :

[INFO] Tagging release with the label 2.0.0...
[INFO] Executing: /bin/sh -c cd /Users/elecharny/mina/trunk && svn --non-interactive copy --file /var/folders/t7/t7UwkHaiGleYYgPqGZTbF++++TM/-Tmp-/maven-scm-409730412.commit --revision XXXXX
[INFO] Working directory: /Users/elecharny/mina/trunk
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: No such revision XXXXX

If so, just type the two following commands :

$ svn up -r HEAD
At revision YYYYYY.
$ mvn -Pserial,apache-release release:prepare -Dresume
[INFO] Release preparation complete.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 4 seconds
[INFO] Finished at: Mon Sep 13 16:12:02 CEST 2010
[INFO] Final Memory: 28M/81M
[INFO] ------------------------------------------------------------------------

Three mails will be generated, and sent to :

svn commit: r996535 - in /mina/trunk: ./ distribution/ mina-core/ mina-example/ mina-filter...
svn commit: r996542 - /mina/tags/2.0.0/
svn commit: r996544 - in /mina/trunk: ./ distribution/ mina-core/ mina-example/ mina-filter...

The first mail tells you that the SNAPSHOT has been moved to the release version in trunk, the second mails tells you that this version has been tagged, and the last mail tells you that trunk has moved to the next version.

Step 4 : perform the release

The last step before launching a vote is to push the potential release to Nexus so that every user can test the created packages. Perform the following actions

$ mvn -Pserial,apache-release release:perform
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Reactor Summary:
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Apache MINA ........................................... SUCCESS [1:05.896s]
[INFO] [INFO] Apache MINA Legal ..................................... SUCCESS [30.708s]
[INFO] [INFO] Apache MINA Core ...................................... SUCCESS [4:44.973s]
[INFO] [INFO] Apache MINA APR Transport ............................. SUCCESS [46.082s]
[INFO] [INFO] Apache MINA Compression Filter ........................ SUCCESS [40.230s]
[INFO] [INFO] Apache MINA State Machine ............................. SUCCESS [52.718s]
[INFO] [INFO] Apache MINA JavaBeans Integration ..................... SUCCESS [46.358s]
[INFO] [INFO] Apache MINA XBean Integration ......................... SUCCESS [1:21.054s]
[INFO] [INFO] Apache MINA OGNL Integration .......................... SUCCESS [40.740s]
[INFO] [INFO] Apache MINA JMX Integration ........................... SUCCESS [40.482s]
[INFO] [INFO] Apache MINA Examples .................................. SUCCESS [1:13.837s]
[INFO] [INFO] Apache MINA Serial Communication support .............. SUCCESS [41.684s]
[INFO] [INFO] Apache MINA Distribution .............................. SUCCESS [12:39.542s]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Total time: 26 minutes 46 seconds
[INFO] [INFO] Finished at: Mon Sep 13 16:45:14 CEST 2010
[INFO] [INFO] Final Memory: 98M/299M
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] Cleaning up after release...
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27 minutes 5 seconds
[INFO] Finished at: Mon Sep 13 16:45:18 CEST 2010
[INFO] Final Memory: 28M/81M
[INFO] ------------------------------------------------------------------------

Done !

Step 5 : closing the staging release on nexus

Now, you have to close the staged project on nexus. In order to do that you must have exported your PGP key to a PGP public server (see

Connect to the Nexus server (, login, and select the MINA staging repository you just created, then click on the
'close' button. You are home...

It's time to launch a vote !

Voting a release

Once the tarballs have been created, and the binaries available in Nexus, a vote can be launched. Simply send a mail on the mailing list describing the new release.

Step 1 : Send a VOTE mail on the mailing list

Here is a sample mail :


<blah blah blah>

Here is the list of fixed issues :

   * [DIRMINA-803 <>]
     - ProtocolCodecFilter.filterWrite() is no longer thread-safe
   * ...

 Here's the Jira link for this version if you'd like to review issues in more details:
 A temporary tag has been created (it can be removed if the vote is not approved):
 The svn revision is :
 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository:
 The distributions are available for download on :
 Let's vote :
 [ ] +1 | Release MINA 2.0.1
 [ ] ±0 | Abstain
 [ ] -1 | Do *NOT*  release MINA 2.0.1

Thanks !

The vote will be open for 72 hours. Once the delay is over, collect the votes, and count the binding +1/-1. If the vote is positive, then we can release.

Step 2 : Close the vote

You can officially close the vote now. There are some more steps to fulfill :

Step 3: Deploy Web Reports (JavaDoc and JXR)

$ svn co<version> mina
$ cd mina
$ mvn -Pserial clean compile site site:deploy

Step 4: Wait 24 hours

We have to wait at least 24 hours for all mirrors to retrieve the uploaded files before making any announcement. I'd recommend you to wait for 48 hours because some mirrors might lag due to various issues.

Step 5: Update the Links in Web Site

Update the links to new distributions in Downloads page.

Step 8: Update related metadata file(s)

Update any related metadata file(s).

Step 9: Wait another 24 hours

We need to wait until any changes made in the web site and metadata file(s) go live.

Step 10: Announce the New Release

An announcement message can be sent to,, and Please note that announcement messages are rejected unless your from-address ends with Plus, you shouldn't forget to post a news to the MINA CWiki space, and run Confluence auto-export plugin manually.

Creating a New Release Branch

When you create a new branch, you have to make sure the sections that specifies branch version numbers are configured appropriately in the root pom.xml.


Please note that the example above is for branches/1.1. For example, you have to replace branches/1.1 with branches/3.0 if the version number of the new branch is 3.0. In case of trunk, it's just trunk rather than branches/<version>.

  • No labels