Tools I use: Ant

I've been using Ant, a build tool for Java. It works pretty well, and overall I'm glad I'm using it. Zocalo builds cleanly on my desktop Mac, my PowerBook, and the linux server at CommerceNet. Any of the platforms will compile, test, and build javadoc or tar files, even when I couldn't find a copy of javadoc without a lot of effort. Ant is much more flexible and powerful than the special purpose shell scripts we used at Agorics. We had all previously used Make, so we knew that that style of approach had its advantages, but Make apparently doesn't really work with complex Java projects, so it's nice that Ant has been built to fill that gap.

But I just don't understand the fascination with XML. XML is a really lousy language for people to interact with directly. I could understand it if people wanted to use XML as an interchange language between programs, but it doesn't seem to have any advantages over s-expressions. The extra syntax just leads to extra possibilities for mistakes, without any value when edited by hand. Shouldn't Ant ship with an editor that lets you fill out a form to create your ant description? Why do we have to hand edit the XML?

Anyway, I also wanted to point out the solution to one of my problems. It took a while to find the right way to invoke JUnit. There's apparently a common problem caused because the ant task for JUnit relies on an optional package that isn't in the standard classpath. Rather than mucking up your classpath for your project with ant's optional tasks, you can just write a recursive call on ant that sets the appropriate classpath and then invokes the simple JUnit task. The details are given on the Open Source Lab's wiki. The recursive call is simple:

<target name="test" description="Run JUnit Via Exec">
   <exec executable="ant">
       <env key="CLASSPATH" path="${basedir}/lib/junit.jar"/>
       <arg line="testTask"/>
   </exec>
</target>

Once you've done that, the JUnit task works correctly, so you can specify which tasks to run using a fileset pattern, rather than enumerating all the test classes as you'd have to do if you tried to work around the classpath problem by execing JUnit directly.

I added one thing to Open Source Lab's suggestion: I wanted a short listing of failures printed out, so I grepped JUnit's output files. All I had to do was add these lines before /target:

<exec executable="egrep">
   <arg line="-r" />
   <arg line="'(Failures: [^0]|Errors: [^0])'" />
   <arg line="TEST" />
</exec>