RichFaces 3.3.X Release Procedure

    This document describes how RichFaces release builds are made. It consists of two parts: environment setup and build process itself.


    Note for community: there's no need to follow this procedure in order to build SNAPSHOT/released version from sources.



    Note: in case of problems, read Troubleshooting section


    Build Environment Settings

    1. JDK 1.5 (SunJDK 1.5.0_22) ONLY should be used. There are back compatibility issues in 1.6 JDK that will not allow RF built using 1.6 to run under 1.5.
    2. Maven 2.0.9/2.0.10 2.2.1 should be used. Maven options environment variable should include:
      1. Necessary memory settings
      2. Locale settings



              MAVEN_OPTS="-Xmx768m -XX:MaxPermSize=256m -Duser.language=en"


    1. Basic cygwin installed if under Windows (bash shell required)
    2. SVN executable is set up and can run in non-interactive mode
    3. Add to settings.xml (example settings.xml file is attached to this article - just change {temp_directory}, {jboss_username} and {jboss_password}):

      User credentials:






















         "local" profile:










         Local temporary repository:



    Release Build Procedure

    1. Execute pre-tagging steps described in: Richfaces 3.3.X release testing process

    2. Notify everybody that branch is closed - post to design forums

    4. Update/checkout clean version of trunk or branch being built

    6. Clear local repository

    8. Revert changes in local copy of richfaces folder in

    10. Update project version in all *.xml; *.sh; *.bat files manually. E.g. replace 3.3.1-SNAPSHOT with 3.3.1.BETA1

    12. Manually update version in framework\impl\src\main\java\org\richfaces\ Check SVN Revision and Date in this file.

    14. Create SVN tag, execute (replace $1 with the actual version number, e.g. 3.3.1.BETA1):

      svn copy checkout$1 -m " create tag for a release $1"


    16. Execute post-tagging steps described in: Richfaces 3.3.X release testing process

    17. Switch to this SVN tag, execute (replace $1 with the actual version number, e.g. 3.3.1.BETA1):

      svn switch$1


    19. Run



      Monitor deployment process – pay attention that artifacts are being deployed under the right version.

      Wait for deployment to complete. Check that artifacts were deployed in local copy of richfaces folder in


    21. Check in distribution files:
      1. SVN Revision and Date in framework\impl\src\main\java\org\richfaces\
      2. important changes since last build. (optional)

    23. Share distribution files with QA Team

    25. QE/Dev Test and work together on issues

    27. Updates to tag or re-tagging may be needed depending on # of updates

    29. When QE/Dev ready - release
    30. Same Release QE tested is uploading to, maven, etc... (Commit from local copy of richfaces folder in


    31. Prep announcement - blog
    32. For GA version only(, 3rd party sites, etc...)


    33. For GA version only: change version number (not in tag, in trunk or branch which was built) to the next SNAPSHOT according to 5) point, then commit changes. Send letters to everybody asking them to update environment
    34. Registration on the project site.
      1. SCP new version to
      2. Register it on the project site:
        1. login to magnolia (how we will share credentials? who will be responsible except me and Jay?(vacation case or other reasons))
        2. Open richfaces project stable downloads page (/richfaces/download/stable.html in tree)
        3. Edit table of downloads(insert proper links) and save.
        4. Open archived releases page. Add new table with previous release to proper group.
        5. Open nightly builds page(/download/nightly.html), correct links to new snapshots.
        6. Open demos page. (richfaces/demos.html) update download links and verify demo location. (probably will be moved in future to jboss.)
    35. Execute binaries post-upload steps described in: Richfaces 3.3.X release testing process
    36. Update Jira so that version shows as "released"
    37. Deploy demo to
      1. For release versions only (GA/SR).
    38. Announce new version
      1. in relation Blog, twitter, forums (personal blogs (e.g. a4j jroller))
      2. For GA version only (, 3rd party sites?, etc...)
      3. Post to design forums that development on next version in svn is open.

    Documentation Release Build Procedure

    Doc release procedure is the following.

    Note: before running the build commands, make sure that the paths in the ENTITIEs (in the master.xml for userguide) are correct for all docs (cdkguide, devguide, etc.)

    • Prepare a zip of release docs:
      1. create a folder named en;
      2. run the mvn clean install -Prelease,docs,release_docs -Dmaven.test.skip=true command from the docs/ directory;
      3. after the build is completed:
        • copy the content of docs/userguide/en/target/docbook/publish/en-US/ to an en/devguide/ folder;
        • copy the content of docs/cdkguide/en/target/docbook/publish/en-US/ to an en/cdkguide/ folder;
        • copy the content of docs/migrationguide/en/target/docbook/publish/en-US/ to an en/migrationguide/ folder;
        • copy the content of docs/photo_album_app_guide/en/target/docbook/publish/en-US/ to an en/realworld/ folder;
      4. edit ui/assembly/pom.xml to reflect the current release version.
      5. run the mvn install -Prelease command from the ui/assembly/ directory;
      6. after the build is completed:
        • copy the content of ui/assembly/target/tlddoc/ to an en/tlddoc/ folder;
        • copy the content of ui/assembly/target/apidocs/ to an en/apidoc/ folder;
      7. edit framework/api/pom.xml to reflect the current release version.
      8. run the mvn javadoc:javadoc command from the framework/api/ directory.
      9. after the build is completed, copy the content of framework/api/target/site/apidocs/ to the en/apidoc_framework/ folder.
      10. edit framework/impl/pom.xml to reflect the current release version.
      11. run the mvn javadoc:javadoc command from the framework/impl/ directory.
      12. after the build is complete, copy the content of framework/impl/target/site/apidocs/ to the en/apidoc_impl/ folder.
      13. create a zip archive of the en directory.
    • Upload the doc bundle onto or make it accessible through anonsvn.
    • Email with the following instructions:
      1. download the docs bundle;
      2. create a new directory at named according to the release version;
      3. copy the contents of the bundle to the new directory.
      4. If required, they may also need to change the latest_3_3_X/ folder to point to the new upload.
    • Check the docs have been uploaded to

    • Discuss some ideas for 4.0 release process - specifically hudson based builds   
      • Targeting BETA1
      • Prabhat and some ideas on hudson configs 

    Third Party Sites

    These sites can be updated to reflect new releases if desired:




    • build fails with org.ajax4jsf.tests.EnumSupportExpressionFactoryWrapper is not abstract and does not override abstract method coerceToType(java.lang.Object,java.lang.Class) in javax.el.ExpressionFactory
    • LRUMapCacheThreadedTest intermitently fails
      • just skip tests: -Dmaven.test.skip=true -DskipTests=true