ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Wood <>
Subject RE: Submission/Proposal: Ant Based Installer
Date Tue, 09 Sep 2003 02:49:25 GMT
To each his own. I'd rather use an existing
tool then re-write what others have already done, unless
there really just isn't anything worth using.

I've used ZeroG InstallAnywhere for 3 years now.
No "scripting" to learn, just drive it from the
IDE. The few times here and there you need something
custom - you write it in java, something you already
know if you are writing tasks for Ant.

I'm not saying don't do it... I'm just saying I was
building installers one hour after starting with InstallAnywhere.
That's after weeks of struggling with a buggy, poorly documented,
clumsy "installshield multi-platform", then finally giving up. 
installshield may be better today, but it wasn't good enough for me
back then...

-----Original Message-----
From: Paul Mclachlan [] 
Sent: Monday, September 08, 2003 9:03 PM
To: Ant Developers List
Subject: Submission/Proposal: Ant Based Installer

Danno Ferrin has in the past been working on something he called 
"inst.ant" - an installer where the install script is written in an ant 

There's a weblog about it at:, but I don't think 
it ever went beyond "alpha/preview" stage.  I'm (slowly) corresponding 
with Danno about this, but it isn't clear to me right now how much of 
this code should survive.

Nevertheless, I need to install one of my Java programs, and, frankly, I 
can't bring myself to learn "InstallShield script", or *anything* 
script.  I already know how to Ant, I think I'd like to write my 
installer using that.

So, I've been hacking. :)

So far, I've added three tasks into a new package called  I can send patches 
for what I'm describing here if you'd like to take a closer look than 
what this email provides.  It isn't ready for checkin (no help, etc, 
etc) yet, I'm emailing just to solict comments. (It does work, though.  
I could slap it up somewhere if there was confusion about what I'm 
trying to describe)

So, the way it works is this.  You add a "create installer" target into 
your build.xml.  My current unit-test one looks like this:

  <target name="dist" depends="compile">
    <mkdir dir="${dist}/lib"/>
    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
    <createInstaller stagingDir="staging" outputJar="installer.jar" 
            <fileset dir="dist"/>


Obviously, you also create an "install.xml".  The unit-test one looks 
like this:

<project name="MyProject" default="simple" basedir=".">

  <target name="simple">
            <directoryDialog addProperty="install.dir"/>
            <install dest="${install.dir}"/>

A couple of observations:

- I'm still toying whether it's Good to do a splash screen with a 
<parallel> like this.  I'm thinking probably I'll code another splash 
screen task instead of using the one that's in there, and not require 
the <parallel> - thoughts, anyone?

- I've tried to mimick existing ant tasks.  directoryDialog uses 
'addProperty' because that's what <input> uses.  <install> is very, very 
similar to <extract>.  Actually, <install> uses <extract> under the 
covers - it supports nested pattern sets in case you want to install 
some of your files in one place and some in another.

- Obviously there's some work on additional UI widgets to be done.  I'm 
a minimalist, I think I'd prefer to provide some very basic ones (splash 
screens, maybe a welcome HTML dialog & a directory selector) and provide 
a way for the user to add their own Swing forms for anything more 
advanced.  It doesn't seem like providing a complete widget set from XML 
really adds much value.

By way of further explanation:

createInstaller creates a .jar file with an embedded copy of most of the 
ant core classes, as well as a manifest with a Main-Class set to a 
little bootstrapper that extracts the "install.xml" to a temporary 
location and invokes any on it.

I've been careful to design it so that unnecessary extracting & copying 
of files isn't done - that's why you have to use the "install" task (to 
get the files directly from the .jar instead of some kind of framework 
that copies ALL the installation data to some temporary location and 
then lets you <copy> or <move> it around from there.

Okay, I think it's time to get to the point of this email.

I'm looking for .. encouragement (heh) I guess.  Is it worth me 
polishing this up and submitting a patch, or is this not a direction you 
guys want Ant to go?  (This is my first post, I'm a complete newbie 
here).  I mean, I need to use it for my project regardless, but I could 
understand if a philosophy of "ant is a build tool, not a $#) 
installer!" prevailed.

Further, (and without seeing the code, obviously), do you think the 
stylistic direction is okay?  I don't want to step on anyone's toes.

Oh, a couple of after-thought practicalities:

- Putting the core ant .class files into the install.jar costs about 1.5 
meg.  That's not insignificant, but for my project, it's a price worth 
paying.  Some work *could* be done to reduce these classes to just what 
was necessary (automatically), but I'm not really inclined to do that.  
(I'm not against it, I just have better things to do than fret over 1.5 
meg. ;)

- I'd be willing to write code that handled the case where no JRE was 
installed on the client system.  (ie, instead of producing a .jar, it 
produces a .exe, or a .bin, or whatever).  But it seems like a "version 
2" type thing.  I don't have an immediate need for it, I'm happy to give 
instructions to *my* users to just install a JRE first...

- The directory dialog is just a swing file dialog with some "prompt to 
create directory if it doesn't exist" functionality.  No big deal.

- A silent version of the installer (or console-mode) could obviously be 
done.  I'd like to out-of-scope it for the initial work, though.

- I'll do some kind of uninstaller, but I'm not sure what form it will 
take yet.  Probably an uninstall.jar put on the user's disk.  I'm not 
sure if it will be automatically generated - quite probably not, given 
for most "simple" installers it'll just be a small ant script deleting a 
particular directory.



To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message