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 | #