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

[Dorian Birsan <birsan@xxxxxxxxxx>]

I'd like to start by commenting on your
last paragraph:

"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).
"

If I understood your scenario correctly, this could be
easily accomplished by having those products define an extra local site
that contains one ("extension") feature. Then all the 3rd party
vendors would provide features whose
colocation-affinity is that feature, so they will get installed in that
particular site.
Is this what you intended ?

-Dorian

Pat McCarthy <patmc@xxxxxxxxxx>
Sent by: platform-update-dev-admin@xxxxxxxxxxx

04/20/2004 01:10 PM

Please respond to
platform-update-dev

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	[platform-update-dev] Update Manager Installs - Forcing the Use of a New Site

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