Based on my requirements, should I use NSIS or jprofiler/install4j

We have a web application that w开发者_如何转开发e need to make easier to deploy for our clients. The current workflow for a fresh install:

• Ensure there is a JRE on machine (32 or 64bit)
• Install Tomcat (32 or 64bit)
• Create a database in Oracle or SQL Server (we provide SQL scripts for this)
• Write some values into our settings table, like hostname. (Can get user to verify these, but dont want user to have to tap them in.
• Create a connections properties file (we provide a mini JAR app to help with this) that will sit under Tomcat.
• We have two WAR files for our actual web application. These can be split across two machines, but for now, lets assume they both get dumped under Tomcat.
• Start Tomcat so that it deploys the WARs

This is a tedious process for our users I want to encapsulate it into an installer and have been looking at doing this in NSIS which seems to have a large community, but then also stumbled across install4j, which although seems to be lesser known, is more specific to java based applications.

Just wanted to get some feedback from more experiennced users out there on the best choice for platform.

I do not want to get half way in, and then realise I have chosen the wrong installer platform.

Disclaimer: My company develops install4j.

First of all, install4j is a commercial tool, so that's a considerable difference to NSIS. Other major differences are:

• install4j is a multi-platform installer builder for Windows, Mac OS X and all POSIX compatible Linux and Unix platforms.
• install4j's main focus is for installing Java-based applications, for example it handles the creation of launchers and services and provides several strategies for bundling JREs. Many things that you need for a Java application will work out of the box.
• install4j provides its own IDE which focuses on ease of use
• Scripting is done in Java. The IDE provides a built-in editor with code-completion and error analysis. Actions, screens and form components have a wide range of "script properties" that allow you to customize the behavior of the installer.

For install4j, I can address your single requirements:

Ensure there is a JRE on machine (32 or 64bit)

In the media wizard, select a JRE bundle. If you select the "dynamic bundle" option, it will only be downloaded if no suitable JRE is found.

Install Tomcat (32 or 64bit)

I would recommend to simply add the root directory of an existing tomcat installation to your distribution tree.

As for the service, you can either use the Tomcat service launcher from the Tomcat distribution or create a service launcher in install4j. In both case you can use the "Install a service" action on order to install the service.

Generated services have the advantage that an update installer knows that they are running and automatically shuts them down before installing any new files.

Create a database in Oracle or SQL Server (we provide SQL scripts for this)

Use the "Run executable or batch file" action in order to run these scripts.

Write some values into our settings table, like hostname. (Can get user to verify these, but dont want user to have to tap them in.

Any kind of user interaction is done with configurable forms. With a couple of text field form components you can query your settings.

This also works transparently in the console installer and the automatically generated response file will allow you to automate installations in unattended mode based on a single execution of the GUI installer.

Create a connections properties file (we provide a mini JAR app to help with this) that will sit under Tomcat.

If you already have a JAR file which does that, just add it under Installer->Custom Code & Resources and add a "Run script" action to your installer to use the classes in your JAR file.

Any user input from form components that has been saved to installer variables can be accessed with calls like

context.getVariable("greetingOption")

in the script property of the "Run script" action (or any other script in install4j).

We have two WAR files for our actual web application. These can be split across two machines, but for now, lets assume they both get dumped under Tomcat.

If you just add the Tomcat directory structure to your distribution tree, you can have these WAR file pre-deployed. Otherwise you can use "Copy file" actions to place the WAR files anywhere.

Start Tomcat so that it deploys the WARs

That's done with the "Start a service" action.