Section 23.4. Maintaining a Distributed Application

23.4. Maintaining a Distributed Application

The deployment is easy if you have the EAR file built properly. But as you just saw, that can be a big "if"the EAR consists of several layers of files that must be in the right place and have the right contents. There are tools to help with all this, though. Ant is widely used to automate many of these tasks.

23.4.1. Ant and CVS

In previous chapters we've talked about CVS for managing sources and Ant for automating our builds. The first step to making all this work together is something that we should have covered soonerusing CVS with Ant.^[2]

^[2] So, aren't you glad that you've kept reading and gotten this far? Ah, the rewards of persistence!

Example 23.7 is a simple Ant buildfile (build.xml) that will let you get the source from your CVS repository by supplying a particular CVS tag. You name the tag (which you would have previously applied to your sources) and this Ant target will check out that version. The files are put in the srctree directory off of the basedir of the Ant project.

You will have to modify this script to make it fit your environment. The cvsRoot and csvRsh values correspond to the CVSROOT and CVS_RSH environment variables that you would otherwise have set for working with CVS. The package attribute should be set to the project directory that you would specify when you check out sources. The directory specified by the dest attribute will be created if it doesn't exist.

The next task to accomplish with Ant is the construction of the EAR, WAR, and JAR files. Since all three files are essentially just JAR files, we can use the Ant jar task. The EAR contains a WAR and a JAR, and those in turn contain Java class files (and a few miscellaneous files). Using the depends attribute, we can build them in steps.

Example 23.7. An Ant target for checking out source from CVS

 <?xml version="1.0"?> <!-- ++++++++++++++++++++++++++++++++++++++++++++++ --> <!--      retrieve our sources by tag name          --> <!--      invoke with: ant -DTAG=puttaghere         --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++ --> <project name="sources" default="src" basedir=".">   <!-- src target -->   <target name="src">     <cvs cvsRoot=":ext:user@hostaddress:/usr/lib/cvs/cvsroot"          cvsRsh="/usr/bin/ssh"          package="projectdir/subproj"          dest="srctree"          tag="${TAG}">     </cvs>   </target> </project> 

Our example (see the book's Web site^[3] for the full listing) only copies prebuilt XML files (the deployment descriptors) into place to be included in the JAR, WAR, and EAR files. For small examples like ours, building the deployment descriptors by hand is not a difficult task. But larger, more complex projects will benefit from further automation. Most J2EE servers come with tools to help build such things. These tools tend to be specific to the particulars of their products. Since the J2EE specification allows for certain vendor variations and configuration differences, they can be helpful in configuring things for your specific vendor's version. But being dependent on them for your deployment is a subtle way to become locked into their product. Another good choiceone that avoids this vendor lock-inis the Open Source tool XDoclet.

^[3] http://www.javalinuxbook.com/

23.4.2. XDoclet

XDoclet is an important tool to help with the automation of EJB-related tasks. Working in conjunction with Ant, it uses the Javadoc mechanism of Java to automate the building of many of the EJB files and deployment descriptors. Recall that Java comments can include special Javadoc tags, such as @author and @param. Javadoc uses these tags to generate HTML files that are the documentation of your Java classes and methods based on the text associated with these tags. XDoclet takes this a step further and defines tags like @ejb.bean and a few dozen more. Then, using the Javadoc mechanism, it can generate all the various pieces required for an EJB. Used this way, you can write a single source file for your EJB, and have XDoclet generate the various home, remote, and local interfaces as well as the deployment descriptors.

So why aren't we all using XDoclet? It has been around for a few years and is gaining a following in the development community. We may be moving in that direction, but it will take some time. It adds yet another layer to what is needed to build an EJB application, albeit a layer that brings some simplification. Later releases of EJB specifications from Sun may subsume its EJB functionality. However, it is still very important to understand the pieces that go together to make an EJB application. One of the favorite quotes from XDoclet in Action by Craig Walls and Norman Richards says it well: "Don't generate what you don't understand."