Page 2 of 2   « previous page

Post-Processing Steps
As with the pre-processing tasks, the post-processing tasks should avoid items such as copying and renaming files. If an archive has to be given a specific name then that name should be handled on the archive task instead of doing a copy or rename. The use of multiple task dependencies should also be minimized to ensure easy traceability and IT compliance.

Testing
One of the common items to do in the post-processing phase is to test. These tests are usually unit tests such as Junit. But these tests can also include some basic tests about the archive itself, such as checking to see if the correct deployment descriptor and properties files have been used or checking the number of files in the archive to verify at a basic level if all of the source was compiled. Another useful test is to check to see if the archive contains the correct manifest and directory structure. Validating these items before deployment can save you the embarrassment of a production failure. It's best if these items are extracted and e-mailed to a tester to verify their accuracy before deployment.

Deployment
The deployment task should be one of the last steps in the build process. It should be dependent on the Testing task and the Testing task dependent on the Build task. But it shouldn't be the default task that gets executed. You want to give the user the option of just building and testing or building, testing and deploying. This lets someone just deploy.

Variable
Beyond the pre-processing, compiling, and post-processing steps in your Ant/XML scripts, managing variables is also critical in creating a more standardized manual process.

Using variables lets an Ant/XML script be written to execute on multiple machines. This is a cautionary tale, however, because using too many variables makes an Ant/XML script hard to read and debug. It's best to use variables for the directory path on the Jar files in the CLASSPATH and for the source code locations. For example, instead of using:

    c:\jdk2\lib\rt.jar you would use ${JAVAHOME}\lib\rt.jar

This reference will let different users have different working locations. Again, the directory structure of the source code and libraries should be laid out efficiently for builds.

Machine-Specific Variables
If there are any machine-specific items referenced in the Ant/XML script then they should be referenced through a variable and abstracted out. When you write the Ant/XML script assume that you won't be the only one using the script.

By following a standard guideline, your Ant/XML scripts can become easier for another developer in your organization to follow and so more traceable. This is ultimately what you're striving for. Traceability in your build process can only be achieved if someone else can follow the build steps. By maintaining some standard sections such as pre-processing, compiling, and post-processing, your scripts should follow a basic structure that can be easily identified and traced.

Commercial Eclipse plug-ins are available that can substantially minimize the need for Ant/XML scripting. These tools provide a reusable build framework through a standardized interface.

Commercial build tools that simply execute your Ant/XML scripts may be helpful in managing the many scripts that are created over time; however, tools that minimize your scripting effort are preferable because they create a solid reusable framework once that can be reused over and over.

The inherent problem of Ant/XML scripting is that the scripts are written for one jar and one application at a time. This creates a lot of redundancy. Redundancy equates to higher cost and lower quality. Just as you strive for reuse when developing applications, you should strive for reuse in your application build framework. Using scripts to do this is close to impossible because manual Ant/XML scripts contain hard-coded application references.

Commercial tools such as Openmake by Catalyst Systems Corporation, Perfect Build by CodeFast, and Builder by Serena address the scripting issue directly by providing a reusable framework in your build process. Open Source tools such as Maven will also assist you in minimizing the amount of scripting necessary for each jar file you create.

As upper management demands more accountability from the development process, the build component will be scrutinized more closely. A point-and-click process from the Eclipse IDE won't meet the new IT mandates. Neither will overly complicated nor non-standardized build scripts. Eventually you'll be forced out of the comfort of your point-and-click IDE and into a more standardized method. Your choices will be to rely on Open Source languages such as Ant/XML and a lot of hard work or a commercial tool to help you with the job. Regardless of your future build requirements, the effort in creating standards for the build is critical and well worth the effort.

References

• www.apache.org - Learn about Ant Tasks, Ant scripting and Maven
• www.openmake.com - Learn about reusable scripts with Openmake
• www.codefast.com - Learn about script generation with Codefast

Page 2 of 2   « previous page