[TRANSIT] rethinking the installer

Stephen McConnell mcconnell at dpml.net
Thu Jan 27 06:06:40 EST 2005


 

> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org 
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of 
> Niclas Hedhman
> Sent: Thursday, 27 January 2005 5:16 PM
> To: DPML Development
> Subject: Re: [TRANSIT] rethinking the installer


Notes inline ...

> 1. As I mentioned to you directly, I don't want to be part of 
> the "Windows Registry Modifying" code release. I have had bad 
> experiences in the past and don't want to go there again.
> This seems to indicate that DPML should not be in the 
> installer business at all, as we discussed in the beginning.  

Just from a pure Windows platform perspective it is simply not possible to
create a working installation without dealing with the registry.  Take our
current transit installer - it creates a DPML home directory, populates the
transit directory with initial settings, updates the ${user.home}/.ant/lib
and exist.  What is does not do is to verify that that the directory is
creating is the actual DPML home nor does it deal with the setup of the PATH
to include the Transit bin directory.  What's missing?  To things are
missing - correct resolution of ${dpml.home} taking into account the
DPML_HOME environment variable and the addition of %DPML_HOME%\bin to the
system PATH environment variable.

Possible solutions:

  1. provide step by step instructions for the user
     on how to do these things (copy A to B, click here
     and declare C, update D with C + E) - i.e. the 
     the most basic and most error prone solution

  2. use a windows installer such nsis and write some 
     scripts that take care of the same thing (this is
     what we did for Merlin)

  3. use a native registry dll and update the registry 
     automatically and have all of the DPML related code 
     in Java

IMO option (1) is not good because it is error prone but more importantly -
it has a very unfinished feel about it.  Option (2) is better but experience
has shown that it is difficult to maintain reliable scripts and the
potential for customization is constrained.  Option (3) resolves both of
these last two issues and enables us to take control of the installation
process.

> I.e. I would like to propose that any and all binary distros 
> from DPML does not tinker with the OS, and external parties 
> are free to offer such conveniences independently.
> A related area is the NT Service runner, which existed for 
> Merlin. Also a piece I would like to bring outside DPML.

I agree. But in doing this we need clarify what installation capabilities
are provided by the DPML distribution. I would suggest a simple zip plus tar
distribution (download, unpack, follow the instructions).

> 2. I must miss the point of what you are trying to do, and 
> what you are really saying.
> Installation of Transit 1.0 is done by downloading some 
> Special-Transit 1.0, which downloads and installs Transit 
> 1.0. So when the day comes to install Transit 1.1... yeah 
> then what ? Either Transit can upgrade itself or it can't. If 
> it can, why is Special-Transit around, and if it can't, why 
> should Special-Transit be any better.

No "Special Transit". 

All that is need is the ability to run transit without an installation
process.  

This is achieved by:

  (a) including the default transit configuration files as 
      bundled resources within the Transit jar

  (b) adding a single class that is declared as the main 
      class that boots Transit with an installer 
      plugin uri (this uri could point to an externally
      managed plugin)

With the above you have transit running (just like we do for Metro) but
instead of running the metro plugin we have Transit running an installer
plugin. The installer plugin does the grunt work of locating any existing
installation, updating configuration files, replacing jar files, etc.  In
the case of a Windows install the installer has available native access to
the registry (bundled as part of the installer plugin and separate from core
Transit).  At a general level the installer plugin pulls down an install
configuration that provides the information about the install options and
related product specific installer plugins.

Cheers, Steve.






More information about the dev-dpml mailing list