[platform-update-dev] Re: platform-update-dev digest, Vol 1 #175 - 7 msg

[Mel Martinez <melm@xxxxxxxxxx>]

Pat,

I am totally with you on this one.   We recognize this need and can't
really wait for a new Eclipse feature, although will adopt one later if it
comes and meets our needs.  As Dorian mentioned, we had some emails on this
before.  We are in fact implementing the type of feature you are
discussing, although perhaps slightly differently.

Here is what we are doing.

Note that our product wraps a subset of eclipse tightly including the
update mgr, so we control tightly how things get installed/updated.
Basically there are two relevant usecases (with all variations sitting
between these two):
1) a new feature install that is completely silent and automated (no user
interaction).
2) a new feature install that is guided by the user (more like the normal
Eclipse Update Manage experience.

In the first case, we want to be able to derive the path that should be
used for the install site for the new feature automatically and just go
ahead and use it.  In the second case, we derive the path and then offer it
as a suggestion to the user, who should of course have the option to
override it via a directory browser.

We take our cue from the way applications typically install on a system.
For example on Windows, an Installer typically generates a default install
path based on a root based on convention ("C:\Program Files") and a
vendor-provided path ("IBM\Widget") to get a default install path
("C:\Program Files\IBM\Widget").   In most installer wizards, the derived
path is offered to the user as an editable field.  There are installers,
though, that do not allow the user to choose the location and put it in a
fixed path because the application can only work in one location.  Also,
many installers support response-file driven 'silent' installs (IBM product
installers are required to support this mode).

We feel the same pattern should be applied to feature installation into the
platform.  Here are exact details on our implementation:

First we need to assertain the default install root.
   We define a preference value belonging to our com.ibm.rcp.provisioning
   plugin and is called 'default.install.root'.   The plugin will set a
   programmatic default of "${PLATFORM_INSTALL}/applications" where
   PLATFORM_INSTALL is the installation directory for our version of the
   Platform.

Next we install features like so:
         We read the feature.xml.
         If a version of this feature is already installed, then we ignore
         the attribute and install in the same location as the existing
         version.
         else we treat as a 'new feature'
            We look in the feature.xml for the colocation-affinity
            attribute
            If the colocation-affinity value is not null and is equal to an
            existing feature id, then we follow the affinity semantics
            described above and install in the same location as the
            referenced feature.
            If the colocation-affinity value is null or is not equal to an
            existing feature id then
               we look inside the feature.properties file for "
               default.install.path" attribute.  If that is not found we
               use the feature.xml's 'label' attribute.  If that is not
               set, we finally fallback on the feature's 'id' as the
               feature's preferred installation path.
               if path is relative (ex.   "file:some/path") then we
               catenate the value onto the default application root
               location (i.e. the "applications/" folder)
               if path  is absolute (ex. "file:/some/path") then we try it,
               but on error we fall back to treating it as relative.


The resulting path calculation is to be used explicitely for silent
installs and offered as the default for interactive installs.  Note that if
the default.install.root would put us in a location we don't have write
privilege to, we fall back to the user's home space.

This could easily be made into a core Eclipse feature by using an Eclipse
Update Manager preference for the "default.install.root" and moving the
optional "default.install.path" from the feature.properties to a full
(optional) attribute of <feature>.

If this were made into a core eclipse feature, we would try to make use of
it directly.

Cheers,

Mel

Dr. Mel Martinez
IBM Rich Client Platform
melm@xxxxxxxxxx




> To: platform-update-dev@xxxxxxxxxxx
> From: Pat McCarthy <patmc@xxxxxxxxxx>
> Date: Tue, 20 Apr 2004 13:10:33 -0400
> Subject: [platform-update-dev] Update Manager Installs - Forcing the
> Use of a New Site
> Reply-To: platform-update-dev@xxxxxxxxxxx
>
> This is a multipart message in MIME format.
> --=_alternative 005E540D85256E7C_=
> Content-Type: text/plain; charset="US-ASCII"
>
> I'm ready to submit a feature request - but want to see what others think

> first.
>
> A long standing issue with an Update Manager supported installs in 2.x
was
> that the default location for a new feature set was the existing product
> directory tree.
> This posed several problems:
> 1) It was considered "bad form" to add your code to another product's dir

> tree (that product would delete you if/when it was uninstalled - even as
> part of an upgrade)
> 2) To do other than the above the user had to do work - ie click on the
> add site button
> 3) If another site was created the install was only known to the active
> workspace.
>
> This led to many teams "positioning" the Update Manager install as a
> "download service only" technology; not to be used for the initial
install
> of new features.  This frustrated others that liked the update manager
> style of adding function (and cost of the associated install routine
> (~=0)).
>
> If existing features from the same provider existed, new features could
be
> added, and many chose to use the colocation-affinity attribute to
identify
> where the new features should be written. This was more than service but
> not the same as a fresh install.
>
> V3 commands for install/add site support go a long way to fixing this, as

> does the single config per product (vs per workspace).
>
> Correct me if I'm wrong - but I don't yet see an answer to the problem of

> adding a feature set from a given provider for the first time.
>
> Is there a way a feature found on an update site can identify either:
> 1) a default install site (c:\tool_install_dir, where the end result is
> c:\tool_install_dir\eclipse\plugins ..\features)
> 2) that a new site must be created (forcing a choice that does not equal
> the existing product site or another linked site)
>
> This could work in concert with colocation-affinity, meaning a
feature.xml
> that said install me next to feature a.b.c if it exists, but if a.b.c is
> not there then either install me here (default install site) or force the

> user to choose a new install site.
>
> This type of processing would be required to support full Update Manager
> implemented installs of new extensions when working with tools that want
> to methodically open themselves for extension by multiple vendors, but
not
> let these vendors add content to the product's install site (or their own

> extension site).
>
> Anybody agree?  Do we need a feature request for this??
>
> Pat McCarthy