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 [mailto:[EMAIL PROTECTED] 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 script. There's a weblog about it at: http://shemnon.com/speling/archives/cat_instant.html, 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 org.apache.tools.ant.taskdefs.optional.installer. 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" installScript="install.xml"> <data> <fileset dir="dist"/> </data> </createInstaller> </target> Obviously, you also create an "install.xml". The unit-test one looks like this: <project name="MyProject" default="simple" basedir="."> <target name="simple"> <parallel> <splash/> <sequential> <directoryDialog addProperty="install.dir"/> <install dest="${install.dir}"/> </sequential> </parallel> </target> </project> 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. Comments/Feedback? Thanks, Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
