Version 50

    Developing with JBoss Cache


    This page is intended as a developer's guide to the JBoss Cache source tree, and in addition to information on the code repositories and tags and branches, also contains details on how to set up and use your IDE's debugger with JBoss Cache.


    Development resources


    Mailing lists


    JBoss Cache developer's mailing list:

    JBoss Cache Subversion commits list:


    Discussion forums


    JBoss Cache user forum:


    JBoss Cache design forum:




    jbosscache on



    Version control information


    Subversion (2.1.0 and beyond)









    Please read SVNRepository for more information on connecting to the JBoss.ORG repositories.


    Tags and branches have been migrated across from CVS, and the new directory structure is shown below.


    Core cache


    /jbosscache/core - core cache


    /jbosscache/core/branches - branches for core cache


    /jbosscache/core/support-branches - branches for core cache, for Red Hat internal support engineers


    /jbosscache/core/tags - tags for core cache


    /jbosscache/core/trunk - HEAD for core cache






    Pojo cache


    /jbosscache/pojo - pojo cache


    /jbosscache/pojo/branches - branches for pojo cache


    /jbosscache/pojo/support-branches - branches for pojo cache, for Red Hat internal support engineers


    /jbosscache/pojo/tags - tags for pojo cache


    /jbosscache/pojo/trunk - HEAD for pojo cache







    Branches and tags


    Tags are simply named after the version, using a point notation (see naming conventions).  E.g., 2.1.0.ALPHA1 or 2.2.0.GA


    Branches are named after the versions that would be tagged off the branch, using a X in place of the variable version.


    E.g., a branch off which 2.0.0.GA, 2.0.0.SP1, 2.0.0.SP2, etc. but not 2.0.1.GA would come off would be called 2.0.0.X.


    E.g., a branch off which 2.0.0.GA, 2.0.0.SP1, 2.0.1.GA, etc. but not 2.1.0.GA would come off would be called 2.0.X.


    E.g., a branch off which 2.0.0.GA, 2.0.0.SP1, 2.0.1.GA, 2.1.0.GA, etc. but not 3.0.0.GA would come off would be called 2.X.


    See 1.4.X and 1.3.X as live examples of this.


    Legacy tags and branches


    Old tags and branches have been imported from CVS, and have been renamed to ensure consistency.  Note that all old tags and branches reside under the core module.


    E.g., the old Branch_JBossCache_1_4_0 is now


    Branches for Red Hat support engineers


    Occasionally Red Hat support engineers may create branches on released versions.  These will live separate from project branches, but follow a similar naming pattern.  E.g.,





    Snapshots will be released to the JBoss Maven2 snapshot repository.  Note that snapshots do not have a release qualifier (.GA, etc.) but instead have the -SNAPSHOT qualifier.  E.g., 2.1.0-SNAPSHOT


    Maven for builds


    We have moved to Maven2 to handle building of JBoss Cache and Pojo Cache.  pom.xml will exist in /jbosscache/core/trunk/ and /jbosscache/pojo/trunk/ to manage library dependencies and documentation.  See README-maven.txt in the source tree for usage information.




    older CVS repository (up to and including 2.0.0.GA)


    Older versions of JBoss Cache used's CVS repository.


    NOTE that this CVS repository is now FROZEN and READ-ONLY.  All active work should happen in the Subversion repository (see above)


    Note that the CVS module name is JBossCache (case sensitive)


    In the examples below, XXX is the tag or branch name.  Beginning with 1.2.4 a source-only distribution is also available from the download site.  For 1.2.2 and earlier, the source for JBossCache was integrated with the JBoss AS code base, so you need to check out JBoss AS code.


    Committer CVS Access


    You would need to make sure your SSH keys are set up on the CVS server.  Your first step should be to read this.


         export CVS_RSH=SSH
         cvs co -r XXX JBossCache



    Anonymous CVS Access


    cvs co -r XXX JBossCache


    Web based access


    Web-based access to JBoss Cache CVS repository is either via:


    CVS tags for released versions



    Label or branch name in CVS

    Location in SVN

    2.0.0.GA "Habanero"


    1.4.1.SP4 "Cayenne"


    1.4.1.SP3 "Cayenne"


    1.4.1.SP2 "Cayenne"


    1.4.1.SP1 "Cayenne"


    1.4.1.GA "Cayenne"


    1.4.0.SP1 "Jalapeno"


    1.4.0.GA "Jalapeno"


    1.3.0.SP4 "Wasabi"


    1.3.0.SP3 "Wasabi"


    1.3.0.SP2 "Wasabi"


    1.3.0.SP1 "Wasabi"


    1.3.0.GA "Wasabi"




    CVS branches for development streams



    Branch name

    Location in SVN


    2.0.x branch

    branch not created as yet

    Ongoing development on the 2.0.x stream

    1.4.x branch


    Ongoing development on the 1.4.x stream

    1.3.x branch


    Unused (except for backports and releasing service packs) on the 1.3.x stream.



    Using Maven


    Maven2 is the preferred approach when developing software with JBoss Cache.  Point your project's pom.xml to to get the latest JBoss Cache releases.  From 2.1.0, JBoss Cache uses the groupId org.jboss.cache and the artifactId jbosscache-core or jbosscache-pojo.




    Point your project's pom.xml to to be able to use snapshots of JBoss Cache.


    Parent POMs


    SeeParent POMs in JBoss Cache for a discussion on parent POMs and how to release them.


    Classpaths with IDEs


    Use the mvn idea:idea or mvn eclipse:eclipse commands to build project files for IDEA or Eclipse.  This sets up your project dependencies, etc. as per the maven2 pom.


    IDEs and debugging


    IntelliJ IDEA


    1.  Set up the project as you would in IntelliJ, by checking out the source tree from CVS.

    2.  Make sure your source directories include src and src-50, and your test-source directories include tests/functional, tests/stress, tests/perf and tests-50/functional



    3.  Make sure your library dependencies include all the jars in lib as well as the etc/ directory and the tests/functional directory (some tests have additional resources there that are looked up using a context class loader)



    4.  Running JUnit tests.  Certain Linux kernels default to IPv6 which screws up a few things with some JDK implementations.  Make sure you force IPv4 by passing in a few VM parameters to IntelliJ's JUnit plugin.  The parameters you'd want are -Dbind.address=



    5.  If you wish to test PojoCache tests and want load-time aspectisation of objects, add the following VM params as well. For JBoss Cache release 1.4.x (using JDK5):


    -javaagent:$\lib-50\jboss-aop-jdk50.jar  -Djboss.aop.path=$\etc\jboss-aop.xml -Dlog4j.configuration=file:$\etc\log4j.xml


    For release 2.x (only supported in JDK5):


    -javaagent:$\lib\jboss-aop-jdk50.jar  -Djboss.aop.path=$\src-50\resources\pojocache-aop.xml -Dlog4j.configuration=file:$\etc\log4j.xml


    Code style


    IntelliJ IDEA


    Download Settings.jar and import it into IDEA using File | Import Settings.  This will only reset the code formatting, and leave everything else - including inspections, JDKs, etc - untouched.  Thanks to Mircea Markus for this tip.




    Download and unzip, and import into Eclipse using Preferences | Java | Code Style | Formatter | Import.


    Continuous Integration


    JBoss Cache uses Hudson for continuous integration. See





    Branch 1.4.x







    You need the docbook-support module from the JBoss AS subversion repository (NOT the old, outdated, frozen CVS repo)


      svn co


    This should be checked out in the same directory you checked out the JBossCache CVS module.  E.g.:,


    FatBastard:~/Code manik$ pwd
    FatBastard:~/Code manik$ ls -l
    total 0
    drwxr-xr-x   29 manik  manik  986 Mar  2 17:10 JBossCache
    drwxr-xr-x    9 manik  manik  306 Feb 28 12:09 docbook-support


    Building docs


    JBoss Cache docs can be built from their docbook sources using:


    FatBastard:~/Code/JBossCache manik$ ./ docs


    from the JBoss Cache root directory.




    HTML and PDF output will be in the docs/BOOK_TITLE/build directory.


    Unit tests


    In order be able to execute the test suite before committing a modification, JBoss Cache runs its test suite in parallel. This requires following some rules and best practices for writing test as well. Please read this for a detailed description: