Developing with JAXB and Ant, Part 1by Joseph Shelby
Ant is a powerful tool for automating tasks in Java development, and can be used quite effectively when dealing with development tools that have odd requirements, or special features like code generation. This article will show the use of Ant when working with a tool like the Java API for XML Binding (JAXB), and in the process show how JAXB can be used with packages, a feature not demonstrated in the examples provided in the JAXB distribution.
Working with XML in Java can be greatly simplified when the developer can utilize type-safe classes that directly reflect the XML tree, rather than abstract DOM (or JDOM) trees that require the elements and attributes to be analyzed. JAXB is being designed and worked on by the Java Community Process, to provide an API and toolset for generating Java source files from an XML DTD and some additional schema specification. JAXB's optimal use is in situations where developers are working with already-existing XML data object specifications. Even in its current early access state, JAXB is quite powerful, with a lot of potential for projects that use XML.
Although the examples provided with JAXB are relatively comprehensive, they don't necessarilly reflect the ideal environments and approaches that Java application developers should use. JAXB provides the means to work with packages, for example, but the distribution provides no examples of such use. Java developers are (or should be) used to using a build tool to automate tasks, and such tools will be useful in automating the generation of Java source files from DTD and XJS files.
Ant is the build tool developed and used by the Jakarta project, a group under the Apache banner, who have been developing a number of open source Java tools and libraries for client-server development (including Tomcat, the Servlet/JSP reference implementation). Though the example here uses JAXB, the technique is also workable for other code-generation tools, such as IDL or RMI. We'll work with refactoring the checkbook example from the JAXB distribution to use packages.
An important step is to lay out a development hierarchy that will separate the generated source files from the source files written by the developer. The user and the build system should be able to clean up and delete auto-generated files without worrying about accidentally deleting the files they themselves have written.
The base hierarchy contains just the
src directory and the data
definitions directory (called
datadefs in this example). The
directory will get the three
.java files that aren't generated
checkbook.xjs files. The test data remains
in the root directory (strictly as a simplification here). The build
system will create the other directories as needed in its
<project name="checkbook" default="test"> <target name="init"> <tstamp/> <mkdir dir="docs"/> <mkdir dir="gensrc"/> <mkdir dir="build"/> </target> </project>
While it's in mind, a matching
clean target should be added:
<target name="clean"> <delete includeEmptyDirs="true"> <fileset dir="build"/> <fileset dir="gensrc"/> <fileset dir="docs"/> </delete> </target>
The directory hierarchy:
root |- src | |- checkbook | |- convertors | | |- TransDate.java | |- demos | |- CheckbookApp.java | |- CheckbookBalance.java |- datadefs | |- checkbook.xjs | |- checkbook.dtd |- checkbook.xml |- march.xml |- build.xml
This could be modified to also delete any generated data files, such as the
_new XML files made by the test program, or text editor backup files.
Pages: 1, 2