Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Installation requirements 
John,

Mark has asked me to look into the Windows installation puzzle, since (of
the three of us here) I'm the most familiar with Windows.

This may be completely lame, but bear with me.

Assume we give up on the notion of a totally portable installer.  The
differences between Windows and Linux installs is pretty significant (esp.
for Stellation servers).  It's probably a lot easier to factor out the
platform-neutral parts (Stellation jars) from the platform-specific
installation scripts.

Would it be reasonable to:
a) pack all the redistributables into one or more self-extracting Jar files
b) Use a WSH (Windows Scripting Host) script to do the Windows-specific parts:
        - Display Welcome screen; prompt for acceptance of license terms
        - Prompt for install location
        - Unpack the jars
        - Register runtime client and/or server components as needed
        - Add desktop and/or Start Menu shortcuts, if desired.
c) Use a complementary script to uninstall Stellation (invoked from Start Menu shortcut; provided with installation-specific details (paths, components installed) from Registry 
    entries made during installation.

Admittedly, this is hardly bulletproof, and a bit kludgy.  However, I did
something fairly similar with WSH about a year ago (installing some PDFTool
components I built), and I believe all the tasks listed above can be
accomplished using WSH (and without installing Ant -- at worst, the end user
might have to get the latest version of WSH from Microsoft, about a 750K
download).

Note: I'm assuming that installation of Firebird (or another db) is outside
the scope of the WSH-based Stellation install.  We should certainly provide
installation instructions:
* Install Firebird first (here's how)
* When Firebird is running, install Stellation
   - Download/Install WSH if necessary (get .exe from MS and run it)
   - Download/Install Stellation (download jar(s) and a couple of scripts;
     run the scripts, answer the prompts and you're done)

This way, the Linux jocks can make beautiful Penguin-oriented scripts
without having to learn about Redmond rituals, and vice versa; everyone can
use the same set of Stellation deliverables from within their installation
incantations; and happiness should reign.

I think this approach should work for a no-frills installation; if someone
wants to build a better installer later, they're more than welcome too.

Comments ?

- Jim


At 04:45 AM 12/18/2002, Jonathan Gossage wrote:

As I see it, the following represents the desired functionality that we will
need in an install/uninstall package. In this discussion I will assume that
we will be able to get permission to redistribute the jar files for Xerces,
Oro and Jdom.

I am also assuming that we will use the Eclipse update mechanism for
upgrades after initial installation.

1. The installation file should be invokable simply by double clicking.

2. The following sequence of steps should take place during installation.

3. Present a Welcome screen.

4. Present a licence screen that supports user acceptance or rejection of
the license.

5. Present a readme screen.

6. Present a dialog allowing the user to select a client installation,
server installation or both.

7. Present a dialog that allows the user to select the installation location
for the files.

8. If the environment does not contain a HOME variable (normal on Windows
systems) request permission to create one. If the user does not allow this,
configuration files will be installed in the root installation directory.

9. Present a dialog/wizard that allows the user to select the database to be
used. This should do the following:
   i) Allow the user to select a supported database.
   ii) Specify a path to the required JDBC driver. The dislog should verify
       the existence of the driver.
   iii) Allow the user to select a database name with the Stellation default
        being proposed.
   iv)  Allow the user to specify the hostname and port where the selected
database can be located.

10. For both client and server installations present a dialog that allows
the user to enter the connection parameters to the Stellation server.

11. Install the client jar files if client installation specified.

12. Install the server jar files.

13. Install the JDBC driver if a server or self-contained installation.

14. Generate a skeletion .svcrc file using the database location information
    from the user.

15. For server installation, generate the appropriate entries to allow the
Stellation server to run as a service under Windows or as a daemon under
Unux. For Windows this will involve adding entries to the Windows registry.

16. Install and tailor the client side launchers if necessary.

Uninstall must perform the following operations.

1. Stop the Stellation server if uninstalling a server installation.

2. Remove registry entries for service management for Windows if
uninstalling a server, or remove entries from system script files on Unix
systems.

3. Remove all files from the installation directory tree.

4. Remove Stellation configuration files from the configuration directory.

However we choose to deliver this functionality I believe we will have to
satisfy the above requirements. I had a look at a number of open source
installers and none of them appear to have the functionality to support all
these requirements.

This leaves us with the following alternatives:

1. Stick with a combination of Ant based installation and manual
configuration. This approach may work in the Unix environment but will not
be well regarded in the Windows environment which has come to expect a much
more automated approach to deployment.

2. Use a commercial installer such as InstallAnywhere. This will allow us to
build a professional installation for all platforms but is somewhat
incompatible with an open source project.

3. Roll our own installer. This option gives us complete control over the
process but involves a substantial effort.

4. Select an open source installer and customize it for our needs. This
could be attractive except for the fact that all the potential candiates
that I examined are licensed under GPL which migh create problems.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx



_______________________________________________
stellation-res mailing list
stellation-res@xxxxxxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/stellation-res


--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email: jim.wright@xxxxxxx

Back to the top