Version 6

    Purpose of this document is to keep track of all necessary steps to perform project release.





    GateIn Dep



    GateIn Parent



    GateIn Common



    GateIn WCI




    Set up build environment

    export TOMCAT_6_0_HOME=path

    export TOMCAT_7_0_HOME=path

    export JBOSS_5_1_HOME=path

    export JBOSS_6_0_HOME=path

    export JBOSS_7_1_1_HOME=path

    export JETTY_6_1_HOME=path

    export GLASSFISH_3_1_HOME=path


    Process GitHub Pull Requests

    You can use your GitHub fork or gatein/gatein-wci master itself to prepare and create a release. Just make sure your origin master is completely in sync with upstream master.


    You MUST NOT perform any --force pushes to upstream.


    Use rebase to keep linear history while processing pull requests.


    Make sure release build works

    mvn clean install -Prelease


    Perform a release

    Create a custom settings.xml for your release (for maximum security use mounted encrypted filesystem, that you unmount afterwards. For a little less security, create a file, and delete it immediately after release is done):


    cat > release-settings.xml << EOF












    (You also need jboss-public-repository defined or a local nexus mirror, so you have to add that to release-settings.xml)


    mvn -s release-settings.xml release:prepare -Prelease


    #Now push tag to upstream master

    git push upstream master --tags


    #Fully build from tag again and upload artifacts to Temporary JBoss Maven Repository

    mvn -s release-settings.xml release:perform -Prelease


    For security reasons delete the release-settings.xml file.


    Check deployed artifacts before releasing

    Log into and go to Staging Repositories. Find the one for your username, and Close it, as explained here.


    You can now browse your temporary repository to check if everything looks ok. Try adding this temporary repository to your settings.xml, empty your local $HOME/.m2/repository and try referencing the released artifact version in another project (i.e. gatein-portal), and build it.


    If everything looks ok, Release the temporary repository. This will make the artifacts publicly visible.


    Update JIRA

    Review changes in the new version relative to previous release. Each new feature, removal of a feature, or a bug fix should have a corresponding JIRA. Close the JIRAs as appropriate - make sure to set 'Fix version' to the released version as appropriate.

    Update 'Fix version' of open jiras targeted to this release to the next version release.





    GateIn PC



    GateIn WSRP



    GateIn SSO



    GateIn Management




    GateIn Portal



    • Make sure all required project components were released (WCI, PC, SSO and so on...)
    • Update component versions to latest released ones.
    • Make sure you download/use clean and right version of application server bundles for packaging


    Maven release

    1. Check if project builds with clean local repository:
      $ mvn clean install -Dmaven.repo.local=/some/local/path/to/empty/dir
    2. Prepare release with maven
      $ mvn clean release:clean release:prepare
    3. Push changes upstream with git
    4. Perform release with maven
      $ mvn release:perform
    5. Go to and log in with credentials
    6. Click “Staging Repositories”
    7. Find matching repository (date and username) and validate it contains proper bits.
    8. Perform first “Close” and then “Release” operation on staging repository. It’ll deploy artifacts and it is not possible to rollback at this point so be careful!.


    Uploading servers and documentation

    1. Go to packaging/release
      $ cd packaging/release
    2. Run ‘’ with proper version as parameter
      $./ 3.3.0.Final
    3. Validate content of ‘packaging/release/test/server-bundles
    4. Go into each server, boot it up and manually check there are no errors in console. For each server access “http://localhost:8080/portal’ and perform few basic operations.
    5. Validate content of ‘packaging/release/upload/docs/’. Open both UserGuide and ReferenceGuide and check there are no obvious errors there.
    6. Run ‘’ with proper version as parameter. This script will upload both documentation and server bundles. It requires proper authorized public key to be used to be able to access server. 
      $ ./ 3.3.0.Final
    7. Script should end up printing set of URLs to the console. Validate that all of those are responding.


    Updating project page

    Updating project page requires access to Magnolia. Changes can be published later when everything is set up. Remember to update all of those places: