James Mead in Hellish XML:
So now you can write test cases for ANT in XML using AntUnit.
You can even write assertions in XML ...
<!-- the actual test case -->
<target name="testTouchCreatesFile">
<au:assertFileDoesntExist file="${foo}"/>
<touch file="${foo}"/>
<au:assertFileExists file="${foo}"/>
</target>
... but why?
The short answer is: Because it is the best way to test Ant tasks.
To answer this in more detail I need to put AntUnit into context a little bit.
Despite its name AntUnit is more about functional and integration testing than unit testing. Nobody suggests you should write unit tests for your Java (or Ruby) project in Ant instead of the testing framework that fits your language or problem domain. In fact Ant will certainly stick with JUnit 3.x for "real" unit tests of its internals.
AntUnit's main purpose was and is testing Ant tasks. As such it is quite natural to express the tests using a language familiar to Ant developers and users - as Ant build files.
Ant's own tests started out as a collection of ad-hoc JUnit tests
in the early days of JUnit 3.x and Ant 1.1 sometime during the summer
of 2000. Pretty soon an Ant domain specific JUnit extension was born,
BuildFileTest
which contains some logic for setting up Ant Project
instances from test build files and a few Ant specific assertion
methods.
Over time many tests degraded to stuff like
public void testSomeSpecificProperty() {
executeTarget("someSpecificProperty");
}
and the actual assertions were performed using <fail> tasks inside of the build file. JUnit wasn't used as a Java testing framework but as a driver for Ant.
We could do better than that, AntUnit was born. Ad-hoc <macrodef>s using <fail> are now replaced by a standard set of assertion tasks and a new task acts as a driver for tests - no reason to abuse JUnit any longer.
There also is an important side effect of using AntUnit as Ant's testing framework: it has become absolutely straight forward to turn a bug report into a test. If a user reports a bug all we need now is a sample build file snippet that exhibits the bug. Glue an assertion at the end and you are done.
path: /en/Apache/Ant/AntUnit | #
Almost three years ago I started to experiment with improved support for .NET development int Ant. It started with support for NAnt and MSBuild - in theory by that time, since MSBuild wasn't available to me. Back then I started with more serious C# development on Mono and the real goal was to be able to drive the whole development of a mixed language project from within Ant.
It's first "micro-release" was more or less an attempt to store a snapshot of my work somewhere other than my hard disk - and strangely to me I received feedback pretty soon. It seemed I wasn't the only one crossing platform boundaries and wanting to stick with Ant.
About a year later, I added NUnit support, which was a real step forward for me since it allowed me to remove NAnt (as much as I liked it) from the build process completely. All development was happening using Mono on MacOS X by that time, I wasn't even sure it work on Microsoft platforms until Steve reported success.
When we started the Antlibs subproject, the .NET tasks were among the first to be added to the sandbox and among the first to be promoted from sandbox to proper. It probably was the first one to receive a bug report as well.
In the mean time I've switched jobs and Microsoft's .NET framework is the primary (but not sole) development platform during the day. This means that the MSBuild and wix tasks have now been tested and actually work.
It also means Mono isn't getting as much testing as I'd like. Yesterday we've released the first beta release of the Ant library, even though Gump says the wsdltodotnet tests are failing on Mono. This should be addressed before the final release, but more testers are not only welcome, you are severely needed.
path: /en/Apache/Ant/dotnet | #
The first beta of Apache Ant 1.7.0 is out.
Ant 1.7 doesn't come with big features that will change the way you do Ant builds like 1.6 did, it is more of a collection of bug fixes plus a set of smaller, yet useful, features.
The mayor new feature is the support for resource collections. Resource collections provide a unification of the existing file collection classes and some non-file "things" you can read from. In particular they
- unify <path>, <fileset>, <filelist> and <dirset> so that <copy> or <apply> (among others) now work on all of those types - use whatever is more appropriate for your use case.
- support set operations and sorting. For example you can now have a union of two <fileset>s, intersect a <path> and a <filelist> or sort a <fileset> by file size.
- Use <zipfileset> or <tarfileset> in many places where only "plain" <fileset>s have been supported before. You can create a tar archive from a zip file by combining the <tar> task with a <zipfileset> for example.
- introduces <url> and CLASSPATH resources as first class resources as well. You can copy things from the CLASSPATH (this includes extracting them from jars) or <gunzip> URLs, fetching and decompressing them on the fly.
The full list of changes is pretty long. My highlights (YMMV):
- <junit> doesn't require junit.jar to be on the CLASSPATH or in ANT_HOME/lib anymore, it will happily work with JUnit on the nested <classpath>.
- <rmic> now properly works on Java 5, there even is support for Mustang's -Xnew argument.
- <junit> supports JUnit 4 out of the box by wrapping JUnit 4 tests in JUnit4TestAdapter internally.
- <get> no longer re-fetches resources that are up-to-date.
- <checksum> supports several different input/output patterns and comes with support for the patterns of the GNU md5sum and BSD's md5 commands.
- <sync> can preserve selected files in the target directory that are not present in the source directory.
As usual you can expect Ant 1.7.0 to be backwards compatible. We tried our best but you might find problems - better give the beta a try, find and report the problems now so that we can fix them prior to the final release 8-).
Even though we've added some initial support for JDK 1.6 and used the Mustang betas to test Ant, there may be problems lurking.
path: /en/Apache/Ant | #
My fellow Ant committer Kev Jackson has written an article for ONJava titled Ant 1.7: Using Antlibs.
While Antlibs have been available since Ant 1.6.0 and Ant 1.7 won't add any big improvements here, they still seem to become more important with Ant 1.7. The reason here is that the Ant project has started (will start, actually) to release new tasks as Antlibs instead of bundling them as optional tasks - three of them are expected to get released soon and work is under way to move the Microsoft Visual Source Safe support to a separate Antlib as well. Others of the more specific tasks are bound to follow.
In his article Kev describes how to use but also how to develop an Antlib, creating an Antlib as a command line wrapper over GNU Arch on his way. He covers testing using JUnit and BuildFileTest as well as AntUnit. He probably is the first one to show a few details of it.
Kev is going to speak at ApacheCon Asia next week, BTW.
path: /en/Apache/Ant | #
I've just committed a new version of the Ant task for the WiX toolkit to Apache's subversion repo. The former version never worked since I forgot to add a few setters. I never claimed I had tested it anyway ;-)
This time it is tested and to prove it, I've added a target to Ant's own build file that uses it. If you have WiX and the .NET Antlib installed, you can now create an MSI installer package for it. No other software required.
This is how it looks:
<dn:wix target="${msi.file}"
mode="both" wixHome="${wix.home}" wixobjDestDir="${wixobj.dir}">
<sources dir="src/etc" includes="*.wxs"/>
<moresources dir="${dist.dir}"/>
<candleParameter name="dist.dir" value="${dist.dir.resolved}"/>
<candleParameter name="version" value="${manifest-version}"/>
</dn:wix>
This will create the MSI file using the .wxs
descriptions in src/etc,
skipping the task if the files in dist.dir haven't
changed. The task combines candle and light
but you can run them separately if you want to.
Writing the .wxs files turned out to be more
cumbersome than I thought - in particular if you have several hundred
HTML files of Javadocs to add. I'll have to sit down and write a task
that does the equivalent of tallow (which isn't
documented in the official manual, see this part of Gabor's
excellent tutorial instead), but in a way that makes the resulting
fragment more predictable (and valid, in the first place). I ended up
running tallow and modifying the result manually.
I haven't even tried to create a UI for the MSI package, but it should be doable with the task as it is.
path: /en/Apache/Ant/dotnet | #