+Firstly, here are some assumptions about the projects which this +document covers: +

+Clarify what you want Ant to do

+Ant is also a great adjunct to an IDE; a way of doing all the housekeeping of +deployment and for clean, automated builds. But a good modern IDE is a +productivity tool in its own right - one you should continue to use. Ant +just lets you give the teams somewhat more freedom in IDE choice - "you can +use whatever you want in development, but Ant for the deployment +builds" Now that many modern open source and commercial IDEs +include Ant support (including jEdit, Forte, Eclipse and IDEA), +developers can use a great IDE, with Ant providing a rigorous and portable +build process integrated into the tool. + +

+Define standard targets +

+ +With standard target names, it is easy to build encompassing Ant build +files which just hand off the work to the classes below using the +ant +task. For example. the clean target could be handed down to the intf and +impl subdirectories from a parent directory + +

+ Extend Ant through new tasks +

+Embrace Automated Testing +

+Ant lets you call JUnit +tasks, which unit test the code your team has written. Automated testing +may seem like extra work at first, but JUnit makes writing unit tests so +easy that you have almost no reason not to. Invest the time in learning +how to use JUnit, write the test cases, and integrate them in a 'test' +target from Ant so that your daily or hourly team build can have the +tests applied automatically. One of the free to download chapters of +Java Development with Ant +shows you how to use JUnit from inside Ant. + +

+Once you add a way to fetch code from the SCM system, either as an Ant +task, in some shell script or batch file or via some continuous +integration tool. the integration test code can be a pure Ant task run +on any box dedicated to the task. This is ideal for verifying that the +build and unit tests work on different targets from the usual +development machines. For example, a Win95/Java1.1 combination could be +used even though no developer would willingly use that configuration +given the choice. + +

+System tests are harder to automate than unit tests, but if you can +write java code to stress large portions of the system - even if the code +can not run as JUnit tasks - then the java +task can be used to invoke them. It is best to specify that you want a +new JVM for these tests, so that a significant crash does not break the +full build. The Junit extensions such as +HttpUnit for web pages, and +Cactus for J2EE and servlet +testing help to expand the testing framework. To test properly you will still +need to invest a lot of effort in getting these to work with your project, and +deriving great unit, system and regression tests - but your customers will love +you for shipping software that works. + +

Learn to Use and love the add-ons to Ant

+The common barriers to cross-platform Ant are the use of command line +tools (exec tasks) which are not portable, path issues, and hard coding +in the location of things. + +

Command Line apps: Exec / + Apply

+Both the command line invocation tasks let you specify which platform +you want the code to run on, so you could write different tasks for each +platform you are targeting. Alternatively, the platform differences +could be handled inside some external code which Ant calls. This can be +some compiled down java in a new task, or an external script file. + +

Cross platform paths

+This difference between platforms (indeed, the whole java classpath +paradigm) can cause hours of fun. + +

+Ant reduces path problems; but does not eliminate them entirely. You +need to put in some effort too. The rules for handling path names are +that 'DOS-like pathnames are handled', 'Unix like paths are handled'. +Disk drives -'C:'- are handled on DOS-based boxes, but placing them in +the build.xml file ruins all chances of portability. Relative file paths +are much more portable. Semicolons work as path separators - a fact which +is useful if your Ant invocation wrapper includes a list of jars as a +defined property in the command line. In the build files you may find it +better to build a classpath by listing individual files (using location= +attributes), or by including a fileset of *.jar in the classpath +definition. +

+There is also the PathConvert task which +can put a fully resolved path into a property. Why do that? Because then +you can use that path in other ways - such as pass it as a parameter to +some application you are calling, or use the replace task to patch it +into a localised shell script or batch file. +

+Note that DOS descended file systems are case insensitive (apart from +the obscure aberration of the WinNT POSIX subsystem run against NTFS), +and that Windows pretends that all file extensions with four or more +letters are also three letter extensions (try DELETE *.jav in your java +directories to see a disastrous example of this). + +

+Ant's policy on case sensitivity is whatever the underlying file system +implements, and its handling of file extensions is that *.jav does not +find any .java files. The Java compiler is of course case sensitive - you can +not have a class 'ExampleThree' implemented in "examplethree.java". + +

+Some tasks only work on one platform - +Chmod being a classic example. These tasks usually result in just a +warning message on an unsupported platform - the rest of the target's +tasks will still be called. Other tasks degrade their functionality on +platforms or Java versions. In particular, any task which adjusts the +timestamp of files can not do so properly on Java 1.1. Tasks which can +do that - Get, Touch and +Unjar/Unwar/Unzip for example, degrade their functionality on +Java1.1, usually resorting to the current timestamp instead. + +

+Finally, Perl makes a good place to wrap up Java invocations cross +platform, rather than batch files. It is included in most Unix +distributions, and is a simple download for Win32 platforms from +ActiveState. A Perl file with .pl extension, the usual Unix +path to perl on the line 1 comment and marked as executable can be run +on Windows, OS/2 and Unix and hence called from Ant without issues. The +perl code can be left to resolve its own platform issues. Don't forget to +set the line endings of the file to the appropriate platform when you +redistribute Perl code; fixCRLF +can do that for you. + + +

Team Development Processes

+Another good tactic is to use a unified directory tree, and add on extra +tools inside that tree. All references can be made relative to the tree. +If team members are expected to add a directory in the project to their +path, then command line tools can be included there - including those +invoked by Ant exec tasks. Put everything under source code control and +you have a one stop shop for getting a build/execute environment purely +from CVS or your equivalent. + + +

Deploying with Ant

+Ant can Jar, Tar or Zip files for deployment, while the +War task extends the jar task +for better servlet deployment. +Jlink is a +jar generation file which lets you merge multiple sub jars. This is +ideal for a build process in which separate jars are generated by sub +projects, yet the final output is a merged jar. Cab can be used on Win32 boxes to +build a cab file which is useful if you still have to target IE deployment. + +

+The ftp task lets you move stuff up to a +server. Beware of putting the ftp password in the build file - a property +file with tight access control is slightly better. The FixCRLF task is often a useful interim step if +you need to to adjust the line endings of files. A +WebDav task has long been discussed, which would provide a more secure +upload to web servers, but it is still in the todo list. Rumour has it +that there is such a task in the jakarta-slide libraries. With MacOS X, +Linux and Windows XP all supporting WebDAV file systems, you may even be able +to use copy to deploy +though a firewall. + +

+EJB deployment is aided by the ejb tasks, +while the +serverdeploy +suite can deploy to multiple servers. The popularity of Ant has +encouraged vendors to produce their own deployment tasks which they +redistribute with their servers. For example, the Tomcat4.1 installation +includes tasks to deploy, undeploy and reload web applications. + +

+Finally, there are of course the fallbacks of just copying files to a +destination using Copy and Copydir , or just sending them to a person or +process using Mail or the attachment +aware MimeMail. +In one project our team even used Ant to build CD images through a build followed +by a long set of Copy tasks, which worked surprisingly well, certainly +easier than when we mailed them to the free email service on +myrealbox.com, then pulled them down from the far end's web browser, which we +were running over WinNT remote desktop connection, that being tunneled +through SSH. + + +

Directory Structures

Simple Project

+Javadoc output can be +directed to a doc/ folder beneath build/, or to doc/javadoc. + +

Interface and Implementation split

Loosely Coupled Sub Projects

+To still have a single build across the sub projects, use parent +build.xml files which call down into the sub projects. +

+This style works well if different teams have different code +access/commitment rights. The risk is that by giving extra leeway to the +sub projects, you can end up with incompatible source, libraries, build +processes and just increase your workload and integration grief all round. +

+The only way to retain control over a fairly loosely integrated +collection of projects is to have a fully automated build +and test process which verifies that everything is still compatible. Sam +Ruby runs one for all the apache java libraries and emails everyone when +something breaks; your own project may be able to make use of +Cruise Control for +an automated, continuous, background build process. + +

Integrated sub projects

+This project style works well if everyone trusts each other and the +sub projects are not too huge or complex. The risk is that a split to a +more loosely coupled design will become a requirement as the projects +progress - but by the time this is realised schedule pressure and +intertwined build files make executing the split well nigh impossible. +If that happens then just keep with it until there is the time to +refactor the project directory structures. + + +

+ Ant Update Policies +

+Often an update will require changes to the build.xml files. Most +changes are intended to be backwards compatible, but sometimes an +incompatible change turns out to be +necessary. That is why doing the update in the lull after a big +milestone is important. It is also why including ant.jar and related +files in the CVS tree helps ensure that old versions of your software +can be still be built. + +

+The most aggressive strategy is to get a weekly or daily snapshot of the +ant source, build it up and use it. This forces you to tweak the +build.xml files more regularly, as new tasks and attributes can take +while to stabilise. You really have to want the new features, enjoy +gratuitous extra work or take pleasure in upsetting your colleagues to +take this approach. + +

+Once you start extending Ant with new tasks, it suddenly becomes much +more tempting to pull down regular builds. The most recent Ant builds +are invariably the best platform for writing your extensions, as you +can take advantage of the regular enhancements to the foundational +classes. It also prevents you from wasting time working on something +which has already been done. A newly submitted task to do something +complex such as talk to EJB engines, SOAP servers or just convert a text +file to uppercase may be almost exactly what you need - so take it, +enhance it and offer up the enhancements to the rest of the world. This +is certainly better than starting work on your 'text case converter' +task on Ant 0.8 in isolation, announcing its existence six months later +and discovering that instead of adulation all you get are helpful +pointers to the existing implementation. The final benefit of being +involved with the process is that it makes it easier for your tasks to +be added with the Ant CVS tree, bringing forward the date when Ant has +taken on all the changes you needed to make to get your project to work. +If that happens you can revert to an official Ant release, and get on +with all the other crises. + +

+You should also get on the dev mailing list +, as it is where the other developers post their work, problems and +experience. The volume can be quite high: 40+ messages a day, so +consider routing it to an email address you don't use for much else. And +don't make everyone on the team subscribe; it can be too much of a +distraction. + + +

+Installing with Ant. +

+The advantage of using Ant is firstly that the same install targets +can be used from your local build files (via an ant invocation +of the install.xml file), and secondly that a basic install target is +quite easy to write. The disadvantages of this approach are that the +destination must have an up to date version of Ant correctly +pre-installed, and Ant doesn't allow you to handle failures well - and a +good installer is all about handling when things go wrong, from files +being in use to jar versions being different. This means that Ant is not +suited for shrink wrapped software, but it does work for deployment and +installation to your local servers. + +

+One major build project I was involved in had an Ant install build file +for the bluestone application server, which would shutdown all four +instances of the app server on a single machine, copy the new version of +the war file (with datestamp and buildstamp) to an archive directory, +clean up the current deployed version of the war and then install the +new version. Because bluestone restarted JVMs on demand, this script was +all you needed for web service deployment. On the systems behind the +firewall, we upped the ante in the deployment process by using the ftp +task to copy out the war and build files, then the telnet task to +remotely invoke the build file. The result was we had automated +recompile and redeploy to local servers from inside our IDE (Jedit) or +the command line, which was simply invaluable. Imagine pressing a button +on your IDE toolbar to build, unit test, deploy and then functional test +your webapp. + +

+One extra trick I added later was a junit test case to run through the +install check list. With tests to verify access permissions on network +drives, approximate clock synchronisation between servers, DNS +functionality, ability to spawn executables and all the other trouble +spots, the install script could automatically do a system health test +during install time and report problems. [The same tests could also be +invoked from a JMX MBean, but that's another story]. + +

+So, Ant is not a substitute for a real installer tool, except in the +special case of servers you control, but in that context it does let +you integrate remote installation with your build. + + + +

+Tips and Tricks

+Debug/release switching can be handled with separate initialisation +targets called before the compile tasks which define the appropriate +properties. Antcall is the trick here, as it allows you to have two paths +of property initialisation in a build file. + +

+It is useful to define a project name property which can be echoed in +the init task. This lets you work out which Ant file is breaking in a +multi file build. + +

+What goes in to the internal Ant tasks depends on your own projects. One +very important tactic is "keep path redefinition down through +references" - you can reuse paths by giving them an ID and then +referring to them via the "refid" attribute you should only need to +define a shared classpath once in the file; filesets can be reused +similarly. + +

+Once you have set up the directory structures, and defined the Ant tasks +it is time to start coding. An early priority must be to set up the +automated test process, as that not only helps ensures that the code +works, it verifies that the build process is working. + +

+And that's it. The build file shouldn't need changing as new source +files get added, only when you want to change the deliverables or part +of the build process. At some point you may want to massively +restructure the entire build process, restructuring projects and the +like, but even then the build file you have should act as a foundation +for a split build file process -just pull out the common properties into +a properties file all build files read in, keep the target names unified +and keep going with the project. Restructuring the source code control +system is often much harder work. + +

The Limits of Ant

It's not a scripting language

+If your build needs to handle exceptions then look at the sound listener +as a simple example of how to write your own listener class. Complex +conditional statements can be handled by having something else do the +tests and then build the appropriate Ant task. XSLT can be used for +this. + +

It's not Make

It's not meant to be a nice language for humans

Big projects still get complicated fast

You still need all the other foundational bits of a software +project

+You also need some kind of change control process, to resist +uncontrolled feature creep. Bugzilla is a simple and low cost tool for +this, using Ant and a continuous test process enables a rapid evolution of code +to adapt to those changes which are inevitable. + +

End piece

Apache Ant Task Design Guidelines

Don't break existing builds

Don't break the Java API

Use built in helper classes

Execute

Java, ExecuteJava

Project and related classes

Obey the Sun/Java style guidelines

+ +It's not that they are better than any alternatives, but they are a +standard and they are what is consistently used in the rest of the +tasks. Code will not be incorporated into the database until it complies +with these. + +

+ +If you are writing a task for your personal or organisational use, you +are free to use whatever style you like. But using the Sun Java style +will help you to become comfortable with the rest of the Ant source, +which may be important. + +

+ +One important rule is 'no tabs'. Use four spaces instead. Not two, +not eight, four. Even if your editor is configured to have a tab of four +spaces, lots of others aren't. Spaces have more consistency across +editors and platforms. Some IDEs (JEdit) can highlight tabs, to stop you +accidentally inserting them. +

+There is an Ant build file check.xml in the main ant directory with runs + checkstyle over + Ant's source code. + +

Attributes and elements

+The Ant 1.x tasks are very inconsistent regarding naming of attributes--some +tasks use source, others src. +Here is a list of preferred attribute names: +

+ + + + + + + + + + + + + + + + + + + + + +

+ failonerror +	+ boolean to control whether failure to execute should throw a + `BuildException` or just print an error. + Parameter validation failures should always throw an error, regardless + of this flag. +
+ destdir +	+ destination directory for output +
+ destfile +	+ destination file for output +
+ srcdir +	+ source directory +
+ srcfile +	+ source file +

+Yes, this is a very short list. Try and be vaguely consistent with the core +tasks, at the very least. + +

Support classpaths

Design for controlled re-use

+ +The other common re-use mechanism in Ant is for one task to create and +configure another. This is fairly simple. There are facilities available in +Ant's API to have the tasks instantiated by their familiar names +("java", "exec", etc.). It is recommended that you +not use this approach because of the entirely real possibility that a +user has overridden the name to point to a different class entirely. Use direct +constructor calls (or reflection) to instantiate your subtask. Since Ant 1.6.3, +you can call org.apache.tools.ant.Task#bindToOwner() +to "mask" a helper task as its parent. + +

Do your own Dependency Checking

Support Java 1.2 through Java 1.5+

+What is problematic is code which is dependent on Java 1.3 features; +e.g. java.lang.reflect.Proxy, or Java 1.4 features; e.g. java.io.nio. +Be also aware of extra methods in older classes; +e.g. StringBuffer#append(StringBuffer). These cannot be used directly +by any code and still be able to compile and run on a Java 1.2 system. +If a new method in an existing class is to be used, it must be used via +reflection and the NoSuchMethodException handled somehow. +

+What if code simply does not work on Java 1.2? It can happen. It will +probably be OK to have the task as an optional task, with compilation +restricted to Java 1.3 or later through build.xml modifications. +Better still, use reflection to link to the classes at run time. +

+Java 1.4 adds a new optional change to the language itself, the +assert keyword, which is only enabled if the compiler is told +to compile 1.4 version source. Clearly with the 1.2 compatibility requirement, +Ant tasks cannot use this keyword. They also need to move away from +using the JUnit assert() method and call assertTrue() +instead. +

Explicitly Expand properties in nested text

Refactor

+ +One thing we must not do is move existing tasks around or delete them. +Remember that Ant has a Java API as well as an XML language. We don't want +to break that API, or anything that subclasses existing Ant tasks. When +refactoring, you need to leave facades where the original classes were. so +existing code does not break. + +

Test

+ +A well written set of test cases will break the Ant task while it is in +development, until the code is actually complete. And every bug which +surfaces later should have a test case added to demonstrate the problem, +and to fix it. + +

+ +The test cases are a great way of testing your task during development. +A simple call to 'build run-test' in the ant source tree will run all ant +tests, to verify that your changes don't break anything. +To test a single task, use the one shot

ant run-single-test
+-Dtestcase=${testname}

where ${testname} +is the name of your test class. + +

+ +The test cases are also used by the committers to verify that changes +and patches do what they say. If you've got test cases it increases your +credibility significantly. To be precise, we hate submissions without +test cases, as it means we have to write them ourselves. This is +something that only gets done if we need the task or it is perceived as +utterly essential to many users. + +

+ +Remember also that Ant 1.x is designed to compile and run on Java 1.2, so +you should test on Java 1.2 as well as any later version which you use. +You ought to be able to download an old SDK from Sun for this purpose. +

+Finally, run a full build test before and after you start +developing your project, to make sure you haven't broken anything else by +accident. + +

Document

+You can use the xdocs stuff in proposal/xdocs to autogenerate your +documentation page from the javadocs of the source; this makes life +easier and will make the transition to a full xdoclet generated +documentation build process trivial. + +

Licensing and Copyright

+ +The fairly laissez-faire license of Apache is not currently considered +compatible with +either the GPL or the Lesser GPL of the Free Software Foundation--the +Gnu project. These licenses have stricter terms, "copyleft", +which are not in the Apache Software Foundation license. +This permits people and organisations to build +commercial and closed source applications atop the Apache libraries and source. + +

+ +Because the Gnu GPL license immediately extends to cover any larger +application (or library, in the case of LGPL) into which it is +incorporated, the Ant team cannot incorporate any task based upon GPL +or LGPL source into the Ant codebase. You are free to submit it, but it +will be politely and firmly rejected. + +

+If you link to a GPL or LGPL library, by import or +reflection, your task must be licensed under the same terms. So tasks +linking to (L)GPL code can't go into the Apache managed codebase. +Tasks calling such code can use the 'exec' or 'java' tasks to run the +programs, as you are just executing them at this point, not linking to +them. +

+Even if we cannot include your task into the Apache codebase, we can +still point to where you host it; just submit a diff to +xdocs/external.html pointing to your task. +

+If your task links directly to proprietary code, we have a different +problem: it is really hard to build the tasks. Please use reflection. + +

Don't re-invent the wheel

+ +If you are thinking of writing a task, posting a note on your thoughts +to the list can be informative--you will get other peoples' insights and +maybe some half-written task to do the basics, all without writing a +line of code. + +

Submitting to Ant

+You may create your patch file using either of the following approaches +(the committers recommend the first): +

+The patches should be sent as an attachment to a message titled [PATCH] +and distinctive one-line summary in the subject of the patch. The +filename/task and the change usually suffices. It's important to include +the changes as an attachment, as too many mailers reformat the text +pasted in, which breaks the patch. +

+Then you wait for one of the committers to commit the patch, if it is +felt appropriate to do so. Bug fixes go in quickly, other changes +often spark a bit of discussion before a (perhaps revised) commit is +made. +

+ +New submissions should be proceeded with [SUBMIT]. The mailer-daemon +will reject any messages over 100KB, so any large update should be +zipped up. If your submission is bigger than that, why not break it up +into separate tasks. +

+ +We also like submissions to be added to +bugzilla, so that they dont get lost. Please submit them by first filing the report with a +meaningful name, then adding files as attachments. Use CVS diff files +please! +

+ +If you hear nothing after a couple of weeks, remind the mailing list. +Sometimes really good submissions get lost in the noise of other issues. +This is particularly the case just prior to a new point release of +the product. At that time anything other than bug fixes will tend +to be neglected. + +

Checklists

Checklist before submitting a patch

Checklist before submitting a new task

AntUnit

+ + Idea +

Initially all tests for Ant tasks were written as individual + JUnit test cases. Pretty + soon it was clear that most tests needed to perform common tasks + like reading a build file, initializing a project instance with + it and executing a target. At this point BuildFileTest + was invented, a base class for almost all task test cases.

BuildFileTest works fine and in fact has been picked up by the Ant-Contrib Project + and others as well.

Over time a new pattern evolved, more and more tests only + executed a target and didn't check any effects. Instead that + target contained the assertions as a <fail> + task. This is an example taken from the build file for the + ANTLR task (using Ant 1.7 features):

+  <target name="test3" depends="setup">
+    <antlr target="antlr.g" outputdirectory="${tmp.dir}"/>
+    <fail>
+      <condition>
+        <!-- to prove each of these files exists;
+             ANTLR >= 2.7.6 leaves behind new (.smap) files as well. -->
+        <resourcecount when="ne" count="5">
+          <fileset dir="${tmp.dir}">
+            <include name="CalcParserTokenTypes.txt" />
+            <include name="CalcParserTokenTypes.java" />
+            <include name="CalcLexer.java" />
+            <include name="CalcParser.java" />
+            <include name="CalcTreeWalker.java" />
+          </fileset>
+        </resourcecount>
+      </condition>
+    </fail>
+  </target>
+

where the corresponding JUnit testcase has been reduced + to

+...
+public class ANTLRTest extends BuildFileTest {
+
+    private final static String TASKDEFS_DIR = "src/etc/testcases/taskdefs/optional/antlr/";
+
+    public ANTLRTest(String name) {
+        super(name);
+    }
+
+    public void setUp() {
+        configureProject(TASKDEFS_DIR + "antlr.xml");
+    }
+
+    public void tearDown() {
+        executeTarget("cleanup");
+    }
+
+    public void test3() {
+        executeTarget("test3");
+    }
+...
+}
+

This approach has a couple of advantages, one of them is that + it is very easy to translate an example build file from a bug + report into a test case. If you ask a user for a testcase for a + given bug in Ant, he now doesn't need to understand JUnit or how + to fit a test into Ant's existing tests any more.

AntUnit takes this approach to testing even further, it + removes JUnit completely and it comes with a set of predefined + <assert> tasks in order to reuse common kind + of checks.

It turns out that AntUnit lends itself as a solution to other + problems as well. The assertions are an easy way to validate a + setup before even starting the build process, for example. + AntUnit could also be used for functional and integration tests + outside of the scope of Ant tasks (assert contents of databases + after running an application, assert contents of HTTP responses + ...). This is an area that will need more research.

+ + Concepts +

+ + antunit Task +

The <antunit> task drives the tests much like + <junit> does for JUnit tests.

When called on a build file, the task will start a new Ant + project for that build file and scan for targets with names + that start with "test". For each such target it then will

Execute the target named setUp, if there is one.
Execute the target itself - if this target depends on + other targets the normal Ant rules apply and the dependent + targets are executed first.
Execute the target names tearDown, if there is one.

+ + Assertions +

The base task is <assertTrue>. It + accepts a single nested condition and throws a subclass of + BuildException named AssertionFailedException if that + condition evaluates to false.

This task could have been implemented using + <macrodef> and <fail>, + but in fact it is a "real" task so that it is possible to + throw a subclass of BuildException. The + <antunit> task catches this exception and + marks the target as failed, any other type of Exception + (including other BuildException) are test errors.

Together with <assertTrue> there are + many predefined assertions for common conditions, most of + these are only macros.

+ + Other Tasks +

The <logcapturer> captures all messages + that pass Ant's logging system and provides them via a + reference inside of the project. If you want to assert + certain log messages, you need to start this task (prior to + your target under test) and use the + <assertLogContains> assertion.

<expectFailure> is a task container that + catches any BuildException thrown by tasks nested into it. If + no exception has been thrown it will cause a test failure (by + throwing an AssertionFailedException).

+ + AntUnitListener +

Part of the library is the AntUnitListener + interface that can be used to record test results. The + <antunit> task accepts arbitrary many listeners and + relays test results to them.

Currently two implementations - + <plainlistener> and xmllistener + modelled after the "plain" and "xml" + JUnit listeners - are bundled with the library.

+ + Examples +

This is a way to test that <touch> + actually creates a file if it doesn't exist:

+<project xmlns:au="antlib:org.apache.ant.antunit">
+  <!-- is called prior to the test -->
+  <target name="setUp">
+    <property name="foo" value="foo"/>
+  </target>
+
+  <!-- is called after the test, even if that caused an error -->
+  <target name="tearDown">
+    <delete file="${foo}" quiet="true"/>
+  </target>
+
+  <!-- the actual test case -->
+  <target name="testTouchCreatesFile">
+    <au:assertFileDoesntExist file="${foo}"/>
+    <touch file="${foo}"/>
+    <au:assertFileExists file="${foo}"/>
+  </target>
+</project>
+

When running a task like

+    <au:antunit>
+      <fileset dir="." includes="touch.xml"/>
+      <au:plainlistener/>
+    </au:antunit>
+

from a buildfile of its own you'll get a result that looks like

+[au:antunit] Build File: /tmp/touch.xml
+[au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.249 sec
+[au:antunit] Target: testTouchCreatesFile took 0.183 sec
+
+BUILD SUCCESSFUL
+Total time: 1 second
+

+ +

bin +	common binaries, scripts - put this on the path. +
build +	This is the tree for building; Ant creates it and can empty it + in the 'clean' project. +
dist +	Distribution outputs go in here; the directory is created in Ant + and clean empties it out +
doc +	Hand crafted documentation +
lib +	Imported Java libraries go in to this directory +
src +	source goes in under this tree in a hierarchy which matches + the package names. The dependency rules of <javac> requires this. +

Ant in Anger: +

+ Using Apache Ant in a Production Development System +

+Steve Loughran +Last updated 2005-03-16 +

Introduction

Core Practices