One of my Bloglines search subscriptions lead me to a (German language) Master Thesis on the "Automatic Creation of Platform Specific Installer Packages for Java Applications" by Christian Elberfeld. I have only skimmed through it (it's 105 pages, after all) but it covers creating MSI files using WiX and creating Debian packages. The source code is available as an open source project (LGPL) at Sourceforge.
Ant itself has been shipping a task for RPM for a long time and the .NET Antlib contains a task to run WiX, but I'm not aware of any other tasks for .deb packages.
In general I've found running the platform specific tools from Ant to be straight forward, the hard part is getting the installation description right for your project and neither Ant's RPM nor WiX task address this. They expect you to write your "spec" or ".wxs" yourself, which can be a pain if you try to create and maintain them for an existing project - at least in the WXS case for WiX where you have to create and maintain GUIDs for all directories you create, for example.
It seems as if the thesis and thus the installer toolkit addressed much of the problem. It tries to generate as much (meta-)information as possible from a single source. There is a central meta-data file that contains license info and such things as well as settings for menu shortcuts that cannot be derived from your sources.
The tedious parts like enumerating all files that are going to be installed is delegated to an Ant task and you don't have to deal with it (or with WiX's tallow.exe's output that needs a lot of post-processing). For WiX writing such a task has been on my TODO list for quite some time, so I'm pretty excited that it might not be necessary, I'll have to take a closer look at the toolkit.
Using this toolkit it seems as if by writing a single straight-forward meta-data file the creation of installers (with GUI) for Debian Packages and Windows MSIs should become pretty easy. The toolkit itself is certainly not complete and I'm sure you'll find a bunch of rough spots or missing features. On the downside the project's svn tree looks as if it hadn't been touched for several months and the choice of license doesn't make me want to contribute.
Sidenote: The Antigen project takes a totally different approach, it uses Ant as the installer engine and wraps it with a GUI. Given Ant's lack of proper exception handling or even rollbacks, I'm not sure how viable this approach is. You'll probably have to use AntContrib's trycatch in a lot of places to ensure you won't be left with a semi-installed product if something goes wrong during the process.
path: /en/Apache/Ant | #
Keeping with a tradition here is how to detect Ant 1.7.0 or later:
<available property="Ant-1.7.0-or-later"
classname="org.apache.tools.ant.types.ResourceCollection"/>
path: /en/Apache/Ant | #
Since "ant junit4" is the search string that's sending most search
engine traffic my way, I should point out that Ant 1.7.0 has been released a
few hours ago. It is supposed to support JUnit4 as well as JUnit3 out
of the box. As an added bonus, junit.jar no longer needs to sit in
ANT_HOME/lib or similar, you can now simply add it to
your <junit>'s tasks nested
<classpath>.
path: /en/Apache/Ant | #
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 | #