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).
Development and Build System with ANT - Automating the Build Process with Apache’s Ant (Page 3 of 11 )
A project with a few files and very little dependencies makes the process of building almost not a process at all. By simply using the Java compiler and maybe the JAR command-line utility, you can build simple Java applications.
Before Ant, developers typically started with a set of simple batch files or shell scripts as an initial step towards automation. But as the number of files, components, target platforms, and View Mail (VM) versions increases so does the build time, the complexity of the build, and the likelihood that human errors will contribute to irreproducible and inconsistent builds. After a while you end up realizing that maintaining a nonportable, platform-dependent homemade solution is cumbersome and error prone.
For the few teams in which developers actually agree on a choice of an IDE, the first choice is usually to use the build facilities provided. Most IDEs provide wizards that build simple applications. These wizards cover only part of the equation and they tie your team to the particular IDE.
Besides the aforementioned problems, both approaches treat development and production environments as being conceptually separate. What’s needed is a low-level tool that can unify the build process across multiple IDEs, stages of development, platforms, and so on.
For many years UNIX programmers have had a way to build their applications via the make utility and all of its variants (GNU Make, nmake, and so on). Like make, Ant (Another Neat Tool) is at its core a build tool, but as the Ant website states that Ant “is kind of like Make, but without Make’s wrinkles.”2
Ant’s simplicity has contributed to its rapid adoption and made it the de facto standard for building applications in the Java world. Ant, together with the Concurrent Versions System (CVS), has played an important role in fostering Open Source by providing a universal way for individuals to obtain, build, and contribute to the Open Source community. Ant has also become an indispensable tool for most Java developers, especially those developing J2EE applications.
Ant is a pure Java application that was originally developed by James Duncan Davidson during a transatlantic flight back to the United States in 1999. Duncan, also the original author of the Apache Tomcat Servlet reference implementation (and one of the J2EE architects), wrote Ant as a tool to ease Tomcat’s building process. As a Sun engineer, he lobbied for Sun to make both projects Open Source by donating the code to the Apache Software Foundation’s Jakarta project. As a reflection of its rising popularity, Ant became an Apache Software Foundation top-level project late in 2002.
Ant has made life easier for Java developers worldwide. Although far from perfect, it has demonstrated that it can cover what Java developers need, from gaining control over the build process to cutting the umbilical cord from proprietary build systems.
The Make Utility and Ant
The make utility is a command-line utility that uses a descriptor or script file (referred to as a “makefile”) that contains dependency rules, macros, and suffix rules that build and test a program. Makefiles contain inference ”rules” that describe how to create a “target.” A target is either a file to be created or an action to be taken. Targets can have dependencies, which might also be targets. Rules in a makefile can form a chain of dependencies that are traversed to accomplish the build. In the C/C++ world, makefiles build object files from source files and then link the object files to create an executable.
A great utility, make does have some “wrinkles,” such as its dependency on UNIX shell scripting and the correlation of targets with files. The make utility’s flexibility and power comes from the fact that it can become a full-blown scripting language that at the same time makes it easier for a makefile to grow rapidly out of control. The same can be said of an Ant build description file, but it seems more likely that problems could occur with the make utility. The make utility’s extensibility comes from the capabilities of the UNIX shell. Ant on the other hand is extended with simple Java classes.
Comparing Ant with the make utility is similar to comparing Java and C or C++. Java was born from some of the lessons learned with C++: Too much flexibility can lead to trouble. Most Ant build scripts are somewhat easier to understand than a corresponding makefile. You’ve probably seen makefiles ranging from difficult to plain cryptic. Makefiles have many features of a bygone developer era such as the need to use control characters like Tab as part of the syntactic rules of the file.
Ant provides a simpler and cleaner way to handle the process of building a Java application. It’s important to acknowledge that the make utility has been around for many years and has benefited from the lessons developers have learned from building a countless number of applications. Some of these lessons are reflected in Ant’s design.
Another marked difference between Ant and the make utility is the fact that Ant is 100-percent Java and thus inherits all of the pros and cons of platform independence. The make utility on the one hand depends on the operating system shell, which gives you all of the power of the UNIX shell but at the same time makes the shell platform dependent. If an application isn’t a Java application there is very little reason to switch from the make utility to Ant. Ant is certainly a Java-centric tool and benefits of its use are seen on Java applications. Although you can make it work with any language due to its extensibility, it isn’t clear that doing so will contribute greatly to the build process of a non-Java application.
Why Choose Ant?
Many people, especially those coming from the UNIX world, ask this question, but the answers seem rather extreme, ranging from the evangelization of Ant to total avoidance. The main point is that Ant does simple things very well. It isn’t perfect and it doesn’t cover every conceivable scenario that can occur in a build, but for the majority of cases it does the job well. The most relevant reasons to choose Ant are as follows:
Platform independence: A typical corporate Java environment includes development teams that work on Wintel machines and deploy to UNIX machines for production. Ant, being a pure Java tool, makes it possible to have a consistent build process regardless of the platform, thereby making the development, staging, integration, and production environments closer to each other. Ant also has built-in capabilities that handle platform differences. Your Java code is portable, therefore your build should be, too!
Adoption: Ant is everywhere! Yes, by itself this is a poor reason to favor a technology but the strengths that ubiquity brings to the table are many including hiring, training, and skills marketability. Ant also has been easily incorporated into many of the leading IDEs, thereby making it the one consistent factor between developers. This is partly due to the choice, for good and bad reasons, of XML as its language.
Functionality and flexibility: For the majority of Java projects, Ant is extensible and highly configurable; it provides the required functionality right out of the box. For Java developers any class can easily become an Ant task, although in our experience we seldom have to write our own tasks (because someone in the Open Source community always seems to beat you to the punch). If desired, you can plug scripting engines (see the Bean Scripting Framework) and run platform-specific commands.
Syntax: Like it or not, XML has become a globally recognized data format. Most Java developers have worked with XML, and J2EE developers deal with XML on a daily basis. XML makes Ant buzzword-compliant. But XML also has some positive advantages. XML is ideal for representing structured data because of its hierarchical nature. The abundance of commercial and Open Source parsers, and the ability to easily check an XML file for well-formness and validation has made the use of XML pervasive in the industry. For more on the debate over XML in Ant see the “Ant’s Future” section later in this chapter.