[platform-update-dev] Re: Update Manager Installs - Forcing the Use of a

[Mel Martinez <melm@xxxxxxxxxx>]

Peter,

We are in no way trying to duplicate a native installer.  We are, however
(as I said) taking a hint or two from them.  It is foolish to ignore
lessons learned there.

There are specific usecases that occur in both worlds and the one we are
concerned about here is pretty fundamental:  Installing a new feature for
the first time.  Where do you put it?

The body of native installers have a compelling convention of offering a
default path suggested by the vendor that the user can choose to override.

This sort of thing is not a hack in any way.  This is an extremely
important feature as it directly impacts useability and serviceability.

I am definitely familiar with thinking of Eclipse as an applications
platform.  Are you familiar with what we are doing with it in our team?  If
not feel free to contact me off-list.

Cheers,

Mel

Dr. Mel Martinez
IBM Rich Client Platform
melm@xxxxxxxxxx

> From: Peter Manahan <manahan@xxxxxxxxxx>
> Date: Tue, 20 Apr 2004 23:13:12 -0400
> Reply-To: platform-update-dev@xxxxxxxxxxx
>
> This is a multipart message in MIME format.
> --=_alternative 0011AE3485256E7D_=
> Content-Type: text/plain; charset="US-ASCII"
>
> To put a little historical slant on things. One of update manager's
> original design goals was to "not" duplicate the function of a native
> installer.  Work with one yes but don't duplicate it. This sounds like a
> move in the direction of implementing a native installer using update
> manager as a base.
>
> The problem with using update manager as a native installer is that
update
> manager understands eclipse features and plugins. So as long as you stick

> to installing plugins and features into eclipse it works fine.  Move
> outside that range and it really doesn't work well at all.
>
> If you need to have features work in the same manner as a native install
> then write a native install. Wrap it in a feature with an installhandler
> if needed but use a native install to talk to the native system.
>
> One perspective is to  look at eclipse as if it were  like an application

> server like WebSphere, WebLogic etc. The server  is installed into the OS

> via  a native installer that understands and works with the OS.
> Application EAR's get installed into the server by the servers'
deployment
> tool which understands the application server.
>
> Install eclipse onto the OS via a native installer and install features
> and plugins into eclipse via Update Manager. Leave each to its specialty
> rather than creating a system that attempts to do everything and then
does
> everything poorly.
>
>  I am just as guilty of doing the similar kinds of hacking of the
features
> in order to get what I need.
>
> We just need to think three or four times on whether pushing those hacks
> into update manager is the best thing for the update manager. Or is there

> a different way to accomplish the same goal. In the case of the path
> problem better interaction with a native install would probably better
> serve the purpose.
>
> Thanks,
>
> -----------------------------------
> Peter Manahan
> IBM Rational Tools
> Common Install
> ------------------------------------
> manahan@xxxxxxxxxx