Home arrow Java arrow Page 6 - Development and Build System with ANT

Development and Build System with ANT

This article will describe some of the development tools that are available from the Java Open Source community and explore how they can help you create high-quality software in a predictable and reproducible fashion, saving you precious time and money. It is taken from chapter three of the book Enterprise Java Development on a Budget, written by Brian Sam-Bodden and Christopher M. Judd (Apress, 2004; ISBN: 1590591259).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 25
September 08, 2005
  1. · Development and Build System with ANT
  2. · Continuous Integration
  3. · Automating the Build Process with Apache’s Ant
  4. · Introduction to Ant
  5. · More on Targets
  6. · Properties
  7. · Case Study: Building the Technology Conference Management System with Ant
  8. · JavaDoc Generation
  9. · Checking Code Conventions with Checkstyle
  10. · Generating Source-Code Metrics
  11. · The all Target

print this article

Development and Build System with ANT - Properties
(Page 6 of 11 )

Ant provides the ability for a project to have a set of properties. Properties are simple strings that you can access using the ${propertyName} notation. Whether you need to specify the location of a needed library many times or the name of a CVS repository, properties give you the flexibility to defer until runtime a set of values to be used in the build.

There are several ways to set a property. You can set it individually to the Ant buildfile via the D command-line option (see Table 3-1), or in bulk, from standard Java properties files by using the propertyfile option.

There are also several tasks that deal with properties. The property task enables the setting of a property by name. All property tasks are idempotent, which means that once a property’s value has been set it will remain unchanged for the remainder of the build. The immutability of properties in Ant is often a source of confusion, because as developers you often tend to think of them as variables.


The <ant> and <antcall> tasks both span a new build by starting another instance of an Ant project. The <ant> task calls an external buildfile, and the <antcall> task calls a target on the current buildfile. For both tasks, all of the properties of the calling project become available on the spawned projects, unless you set the inheritAll attribute to false, in which case only those properties passed on the command line become available to the spawned projects.

The simplest way to set a property’s value is to use the property task. For example. To set a property named src, which could be later accessed using ${src}, you would use the property task as follows:

<property name="src" location="src" />

The src property would be an absolute path that refers to the location of the src directory relative to the basedir directory.


Properties should be used with care. The two main uses of properties are, for items whose value might change from build to build or for items whose value is calculated and used more than once during the build.

Many Ant properties are also available implicitly and are composed from the system properties such as ${java.version}.

For any but the simplest project you can load a property file using the file attribute of the property task, thereby taking into account differences in user configurations, as follows:

<property file="build.properties"/>

Other tasks that deal directly with properties include the following:

  • LoadProperties: Loads the contents of a file as properties (equivalent to using the file attribute for the property task.


  • LoadFile: Loads a text file into a single property.


  • XMLProperty: Loads properties from an XML file. See the Ant documentation for the specific format of the XML file.


  • EchoProperties: Displays all available properties in the project.


Many other tasks use properties as a way to take parameters in or out. For example, a common practice is for a task to have an attribute that takes the name of an nonexistent property to be set in case of a specific event, such as the possibility of the task failing.


We recommend using a properties file named build.properties to store any overridden default values. This property file shouldn’t be kept in the source-code repository, but instead you should add a sample properties file named build.properties.sample along with instructions on how to configure the build.properties file.


Ant’s datatypes are primitive constructs that provide frequently required information in the processing of a buildfile. Their purpose is to simplify a task by encapsulating some information required and providing a simple way to manipulate it.

Several of Ant’s built-in datatypes provide a structure that encapsulates information about a set of related resources such as files, environment variables, or even complex mappings between input and output files. Knowing how to properly use the Ant’s datatypes will help you kept your buildfiles simple and efficient.

Datatypes and Properties in Action: A Simple Example

Many of Ant’s tasks need to manipulate a file or groups of files. A typical need in a build is to specify a set of JAR files to be included in the classpath for certain tasks. Imagine that you’re building a simple application with a directory structure, as shown in Figure 3-4.

Figure 3-4.  Sample directory structure for datatypes and properties

The following sample buildfile snippet shows a build for which two path structures (datatypes) are defined, one with an id of class.path and the other with an id of all.source.path. These two datatypes are then used in the target named compile, which uses the javac task to compile the classes referenced by the path reference by the id all.source.path.

<?xml version="1.0"?>
<project name="My Build" default="all" basedir=".">
<property name="lib" location="lib"/>
    <property name="src" location="src"/>
    <property name="classes" location="classes"/>
    <property name="build" location="build"/>
<property name="src-java" location="${src}/java"/> 
    <property name="src-generated" location="${build}/generated-code/java"/>
    <property name="struts-lib" location="${lib}/struts"/>
    <path id="class.path">
        <fileset dir="${lib}">
<include name="*.jar"/>
        <fileset dir="${struts-lib}">
<include name="*.jar"/>
<path id="all.source.path">
        <pathelement path="${src-java}"/>
        <pathelement path="${src-generated}"/>
    <target name="compile" description="Compiles all sources.">
<path refid="all.source.path"/>

The class.path path structure uses two instances of the fileset datatype to group under a common classpath all the JAR files included in the directories referenced by the lib and struts-lib properties. The path element is an example of an indispensable datatype that enables you to reuse path information in your builds. The fileset datatype is a typical example of Ant’s pathlike structures. It encapsulates a group of files defined via nested patternset structures. For example, to create a fileset that includes all JAR files under the ${lib} directory, you can use the following fileset definition:

<fileset dir="${lib}">
      <include name="*.jar"/>

The fileset datatype contains an implicit patternset structure, which means that you can use shorthand to rewrite the fileset definition as follows:

<fileset dir="${lib}">
<include name="*.jar"/>

You can further compact the fileset definition by using the include in the property form, rather than as a nested element:

<fileset dir=”${lib} include=”*.jar” />

The path datatype can also make use of nested pathelements, as shown in the definition of the all.source.path path structure. It uses the pathelement datatype to reference the locations defined by src-java and src-generated properties.

Path is a typical Ant pathlike structure. When dealing with paths or classpaths, Ant provides pathlike structures that can be used as nested elements on most tasks. In the previous example, you can see that the two pathelements defined at the top of the buildfile are then used by reference in the context of the javac task. The class.path path is passed to the classpathref attribute of javac to determine the classpath for compilation and the all.source.path is used by creating a new pathelement, which is nested inside the src nested element of the javac task.

As a build’s complexity increases so do the patterns for selecting files. Pathlike structures enable the reuse of path information and help keep the growth of buildfiles under control.


One of the criteria used in choosing many of the tools in this chapter was whether the tool provided an Ant task.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials