ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Developing with JAXB and Ant, Part 1

by Joseph Shelby
03/06/2002

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.

Directory Hierarchy

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 src directory will get the three .java files that aren't generated (CheckbookApp, CheckbookBalance, and TransDate), and datadefs will get the checkbook.dtd and 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 init target:

<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

Next Pagearrow