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

[Dorian Birsan <birsan@xxxxxxxxxx>]

Mel,

In the context of post eclipse 3.0,
the update team would be very interested to work with you to get some of
your code into eclipse.
On a first reading, I'd say that most
of what you're doing could make it, and my only major disagreement is with
support for absolute paths.
Absolute paths should not be supported,
or only supported for signed features. This may need some work, unless
there is a way to indicate linked sites, which, currently, are specified
as absolute url's. At some point there were discussions about variable
path subsitutions, but that discussion stalled.
Also, we need to ensure that existing
files are not overriden by installs.


-Dorian

Mel Martinez <melm@xxxxxxxxxx>
Sent by: platform-update-dev-admin@xxxxxxxxxxx

04/20/2004 09:01 PM

Please respond to
platform-update-dev

To	platform-update-dev@xxxxxxxxxxx
cc	Pat McCarthy <patmc@xxxxxxxxxx>, Mel Martinez <melm@xxxxxxxxxx>
Subject	[platform-update-dev] Re: platform-update-dev digest, Vol 1 #175 - 7 msgs

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

_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev