I helped write a java program a few months ago, a product designed to run on mail servers. Now, we had the program packaged up as a zip file (for windows) and a tarball (for unix). That wasn’t my decision, but it makes sense to me–if you are deploying a program on a mail server, you should know how to unzip files and edit configuration files.

But, that’s not what the client wanted. They came back recently with a few changes, and a desire to install via InstallAnywhere. I am no expert at InstallAnywhere, but the client didn’t have the engineering cycles to repackage the program, so they paid me to do it. What follows is my overall impression of InstallAnywhere, and a few tips and tricks.

Overall, I like InstallAnywhere. This program makes it easy to build java program installers for a variety of different platforms (most of the unices, Macs and Windows), execute sundry actions pre and post install, and grab user input while installing. It supports both GUI and console installation procedures. In particular, the Windows installer was a snap, and I didn’t have to learn the first thing about the registry–InstallAnywhere took care of that, even to the point of having the program show up on the ‘Add/Remove Programs’ Control Panel.

On the downside, there are a bevy of options and the help file wasn’t exactly the best. They have a free trial version, but it complains every time you install from a file built with the trial version; such installers stop working around 10 days after you build with the trial version as well–but the trial version doesn’t tell you about the future failure.

A few tips:

* It’s possible to keep the install configuration file in CVS, except for the fact that it hardcodes paths to resources that it includes in the install file. I was able to work around that by using ant’s replace task.

* When you start up the program (on unix), you can’t kill it normally, via either cntrl-c or backgrounding it and running the kill command on the process. I believe this is because the default behavior of a launcher is to listen to the console for stdin. You can change this easily enough, but the default really should be correct.

* The installer builder doesn’t default to generating a log, even though many of the default log messages point you to the install log file. You have to click a checkbox on the Project Info Pane in the Advance Installer.

* The console installer insisted that there were errors in the installation process even though the program, post install, worked fine and there were no errors written in the installer log. I think this is due to the fact that I’m using the trial version, but am not sure.

* There doesn’t seem to be any way in the InstallAnywhere GUI to specify that if the DISPLAY variable is set (on unix systems), the GUI installer should run, otherwise the console installer should run. If you want, you can edit the generated install.bin installer script–search for ‘FAILSAFE’ and use a modern editor capable of long lines–but I couldn’t figure out a way to automate this change. This is my biggest gripe, since this is a very typical demand. If you don’t run install.bin -i console to specify a console installation, you get a lovely exception:

Stack Trace:
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159)
        at java.awt.Window.(Window.java:317)
        at java.awt.Frame.(Frame.java:419)
        at java.awt.Frame.(Frame.java:384)
        at javax.swing.JFrame.(JFrame.java:150)
        at com.zerog.ia.installer.LifeCycleManager.f(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Overall, I’d say if you’re delivering a java based product to typical users, InstallAnywhere is a good choice. I don’t know how much it costs, but the experience for the users is as seamless as you want it to be, the width and breadth of installer customization is impressive, and it didn’t take too long to get up to speed.

10 thoughts on “InstallAnywhere Impressions

  1. moore says:

    I did an install anywhere demo for someone a few months ago. The details are now hazy, but I believe you can use install anywhere variables to avoid using the ant replacement techniques when storing a iap_xml file in CVS (or any other version control system).

  2. Jesse says:

    Yes, you can indeed use variables to specify a “root” for your resources so all files added under that root will be relative to that root. Then another developer can have their resources in a different location as long as they specify the “root” location variable correctly IA will be able to resolve all the resource files.

  3. moore says:

    FYI, here’s content from an email I got from the folks who make Install Anywhere:

    ———————-
    On December 31, 2008, Acresso Software is discontinuing its support for all editions of InstallAnywhere™ 7 and InstallShield 11 and 11.5. Acresso must occasionally retire older versions to focus on improving our current releases.

    To help you move to the latest release, Acresso is giving you a special offer: Save 10% off the upgrade price* when you move to InstallShield 2009 or InstallAnywhere 2008 VP1 by September 30, 2008! Please use promo code 6J8U2X to receive this special upgrade discount.
    ———————–

  4. Daniel says:

    Hi,

    If in the future you need to create cross-platform installers for a Java product, you may want to consider BitRock InstallBuilder. We address out of the box many of the issues you mention: we provide a human-friendly XML project file that can be integrated in version control systems, when no GUI mode is available the installer degrades to a text-based install, it is possible to store paths in a relative way. In addition, since the generated installers are native, they do not require a self-extraction step or bundling a JRE so they are smallers and faster to startup

  5. moore says:

    Hi Matt,

    Thanks for pointing me to that script solution. Very cool!

  6. Matt McGinty says:

    Sure thing.
    It has also been suggested to me that I should search in the InstallAnywhere source files for the startup shell stub (“rgrep -r FAILOVER /path/to/install/anywhere”)
    and do the replacement once in there.

    In theory, afte doing that… all installers generated by that given InstallAnywhere installation would contain these changes.
    Essentially it would be modifying the InstallAnywhere installation.
    You’d do it just once per IA installation.

    Thus far I’ve not been able to locate that stub (I have IA 2008 Enterprise running on Windows Vista x64).

    And then there is also the matter of the un-installer script and whether or not it would default to console mode on a headless system….

    Matt

  7. Matt McGinty says:

    I just tested and found that the uninstaller will also run in console mode.
    I simply used an installer that had been modified using the script in SE FAQ #385 (and ran it on a Linux system where I had performed “unset DISPLAY” to make it headless).

    I believe the uninstaller will run in whatever mode the installer had been run in.
    So that part requires no additional effort.

    Matt

  8. moore says:

    Hi Matt,

    I’m not sure I’m a fan of “modifying the InstallAnywhere installation”. Doesn’t that raise maintenance issues?

Comments are closed.


© Moore Consulting, 2003-2017 +