all: project.jar project.jar: Main.class XmlStuff.class jar -cvf $@ $< %.class: %.java javac $< in Java

Encoder ECC200 in Java all: project.jar project.jar: Main.class XmlStuff.class jar -cvf $@ $< %.class: %.java javac $<

The makefile has a phony target, all, which, by virtue of being first in the file, is the default. The real target is project.jar, which depends on two compiled Java files. The final rule states how to build class (.class) files from Java (.java) files. In Make, you list the file dependencies, and the run time determines which rules to apply and in what sequence, while the developer is left tracking down bugs related to the need for invisible tab characters rather than spaces at the start of each action. Make works well on a platform in which the underlying tools are good at performing the different tasks of the build process (which is why it excels on a Unix system) and when all dependencies are quite simple. It is language-independent, flexible, and widely understood.

When the build stages do not generate local files but issue commands to SQL databases or deploy software to remote servers, the simple dependency checking of Make does not work so well. It is possible to execute these tasks, but the makefile gets more and more complex, making maintenance of the build a full-time operation. How Ant is not Make Besides learning the core concepts of Ant, it is important to forget preconceptions that come with extensive use of Make. The two tools have the same role: they automate a build process by taking a specification file and performing a sequence of operations based on the content of that file and the state of the file system. Even ignoring operational details such as the different syntax and means of executing targets, Ant and Make have some fundamentally different views of how the build process should work. With Ant, you list sequences of operations and dependencies between them, and let file dependencies sort themselves out through code that understands each operation in the build process. The only targets that Ant supports are those like Make s phony targets: targets that are not files and exist only in the build file. The dependencies of these targets are other targets. You omit file dependencies, along with any file conversion rules. Instead, the Ant build file states the stages used in the process, and while you may name the input or output files often you can use a wild card or even a default wild card to specify the source files. For example, here the <javac> task automatically includes all Java files in all subdirectories below the source directory:

< xml version="1.0" > <project name="makefile" default="all"> <target name="all"> <javac srcdir="."/> <jar destfile="project.jar" includes="*.class" /> </target> </project>

Both the <javac> and <jar> tasks will compare the sources and the destinations and decide which to compile or add to the archive. Ant must call every task in the target-derived order, and the tasks can choose whether or not to do work. The advantage of this approach is that the tasks can contain more domain-specific knowledge than the build tool, such as performing directory hierarchy-aware dependency checking, or even addressing dependency issues across a network: Ant s FTP and HTTP tasks can use dependency checking to manage their downloads or uploads. The other subtlety of using wildcards to describe source files, JAR files on the classpath, and the like is that you can add new files without having to edit the build file. This is nice when projects start to grow it keeps build file maintenance to a minimum. It may seem that invoking tasks to check dependencies adds overhead to the execution, but because most tasks are just Java classes that are loaded into the current JVM, there is little overhead compared to having the run time do any file dependency checking. Even when a task works by executing a native application, the Java code can perform the task-specific dependency checking before calling that native program. 12