I am now a strong advocate of the 'Java Blueprints Guidelines'

Tue, 30 Aug 2005 21:48:11 GMT

After using different project taxonomy conventions, including some of my own bad ideas. I think I finally found one that is flexible for all my projects. At first, when I saw this page, I thought that the people at Sun Microsystems were insane to make the j2ee project conventions so complicated.

Currently, I manage four j2ee style applications for my customers, and everytime I needed to add a war, another ear, another jar, or even a har (hibernate archive), my folders became a mess and so did the build files associated with them. Finally, given all the chaos that I suffered, I decided to give these J2EE project conventions a try to see if it offered some relief of my pain, and it sure did.

Strategy for J2EE Applications 1.0

I also added a few items and rules to this convention for my own use that I think you may find useful, or not.

In the apps category, my personal rule is that if it is going to create an archive you must have a folder for it. So the way I would do a typical one ear contains one war and one jar would be something like this:

apps
|-myproject-ear
     |-myproject-war
     |    |-lib
     |    |-src
     |    |-test
     |-myproject-jar
     |    |-lib
     |    |-src
     |    |-test
     |-src
     |   |-conf
     |      |-application.xml
     |-build.xml

Another rule I made for myself is that the components directory is solely externals code from another subversion (or CVS for you old-timers) repository. Items that come in binary form and not in source code form will be placed in their respective lib directories. Now, throwing in a complicated scenario. Lets say that I will have a java web start application that will of course be placed into a war in some webpage. That war will then be placed in an ear file that can then be placed onto an application server. There could be many possible solutions to this, and here is a diagram of what I would be offering. I would think that this would be the best solution because the webstart application can be developed and tested (usually by another group) in it's own environment.

apps
  |-myproject-ear
     |-myproject-war
     |    |-lib
     |    |-src
     |    |-test
     |-myproject-jar
     |    |-lib
     |    |-src
     |    |-test
     |-src
     |   |-conf
     |      |-application.xml
     |-build.xml
components
  |-webstart-jar (as an external)
    |-src
    |-lib
    |-test

Some other solutions to the previous scenario would be to include webstart-jar under myproject-war, or as a sibling to myproject-war or myproject-jar. In the long run, it seems that placing it under the components directory would be more IDE friendly. I also have a couple of very important additions to these conventions. One is that there needs to be a java directory under the test folder. This would take care application tests that are developed in another computer language. The test folder also needs a conf directory to contain files, resources, etc that are required by the test classes. Lastly I believe that this structure can be also be used for non-J2EE apps, and used for any "uber-projects", even those projects that include code from other programming languages. I am going to stick with this for a while and see if I can come up with scenarios that this wouldn't work, and as always, I welcome your comments.

Evolutionnext Latest DesignPatterns blog entries

I am now a strong advocate of the 'Java Blueprints Guidelines'