Home > Ant Introduction > Ant Primer

Ant Primer



apache ant 


Ant Origin:

Ant was conceived by James Duncan Davidson while turning a product from Sun into open source. That product, Sun’s reference JSP/Servlet engine, later became Apache Tomcat. A proprietary version of Make was used to build it on the Solaris Operating Environment, but in the open source world there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple platform-independent tool to build Tomcat from directives in an XML “build file”. From this humble beginning, the tool has gone on to become more widespread than the Tomcat product for which it was created. Ant (version 1.1) was officially released as a stand-alone product on July 19, 2000. Today, Ant is the build tool used by most Java development projects. Most open source developers include build.xml files with their distribution.


Ant Introduction:

In recent years, Open Source tool Ant has become the de facto standard for building Java projects. Like its venerable ancestor Make, Ant controls the steps necessary to compile, package, and arrange the files that make up your development project. Built with Java, Ant has been designed to be easy to use, flexible, and platform independent.

Apache Ant is an Apache Jakarta project. It is open source software, and is released under the Apache Software License. It is a java-based tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects. The most immediately noticeable difference between Ant and Make is that, Ant uses XML to describe the build process and its dependencies, whereas Make has its Makefile format. By default the XML file is named build.xml.

All modern Java IDEs integrate with it, most open-source Java projects use it. If you are developing Java software and not using Ant, then chances are you’re doing things the hard way. It’s relatively easy to craft an Ant build file by cutting and pasting pieces from other build files, but we don’t want to get into a situation where maintaining the build process is a full-time job. It is important to understand Ant’s capabilities in order to avoid hacking build files. By understanding Ant’s basic data types, syntax, and properties and applying some simple best practice techniques, the build process can be easily controlled, extended, and reused.

ANT enables you to automate the build deploy process of your server-side Java Web components as well, such as custom tags, servlets, and JSPs. Ant gets its cross-platform support by relying on Java for file access, compilation, and other tasks. Ant is extensible through its support for scripting (Jython and NetRexx, among others), Java custom tasks, and the ability to call OS commands, executables, and shell scripts via an Ant exec task (normally a lastresort measure). Ant makes continuous integration possible for server-side components with its automated build script and integration with JUnit, a unit-testing framework for Java.

Developing in the J2EE environment can be tricky, with its multitude of deployment descriptors and configuration files. In addition, these files often need to be configured and reconfigured for each deployment environment, and for each application the components will be deployed in and for each phase in the development process. After all, the advantage of using components is that they can be reused by many applications–and you are not going to deploy your application and components without going through the full development cycle. You may want to deploy to different servers; say you need to deploy to your development server (maybe a local Windows box), then your integration server (Solaris or Linux), then to the QA server–and one day, to your production server. Now, each of these application server instances will likely use different instances of your datastore (MySQL, SQL Server, Oracle, etc.). Then add the fact that you may be trying to deploy your components to different application servers, and your build process can quickly become too complex.

Ant comes to the rescue, allowing you to automate your build and deploy process. Ant lets you manage the complexities of component development and make continuous integration with J2EE development possible from a single build.xml file.

As Ant build file comes in the form of an XML document, all that is required is a simple text editor to edit the build file(s). An editor that provides XML syntax highlighting is preferable. The Ant installation comes with a JAXP-Compliant XML parser, this means that the installation of an external XML parser is not necessary.


Ant’s Principles:

  • Simplicity
  • Understandability
  • Extensibility


Ant’s Core concepts:

  • Declarative
  • XML build file
  • One project per build file
  • Each project contains multiple targets
  • Targets may depend on other targets
  • Targets contain tasks


Ant can:

  • Help with database driven applications
  • Take care of J2ee deployment descriptors
  • Allow developers to use IDE of their choice
  • Enhance deployment quality
  • Deploy strictly to production systems
  • provide developer and build parameterization


Other Java-based build tools are Maven and JavaMake.





Note: Refer to other posts in Ant category for further knowledge.



  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: