Re: [platform-update-dev] eclipse installation site types cleanup

[Peter Manahan <manahan@xxxxxxxxxx>]

Understood and agreed :-) We are on
the same page I think.

.We have multiple products that all
link together. The first product to get installed  "hosts"
the eclipse platform the other products make use of.  After a bunch
of reference counting later its possible to pop the different products
on and off the system without losing the original workbench instance unless
they all disappear.  

The main reason  for just using
the addsite commands beyond those you mention is consistency. We have to
do it in other places as well (downloading tech previews , checking the
consistency of the features/sites installed etc) so only having one method
of working with eclipses's config  is simpler I think. 

So we still would like the removeSite
command added :-)

Thanks,

-----------------------------------
Peter Manahan
IBM Rational Tools
Common Install
------------------------------------
manahan@xxxxxxxxxx

Dorian Birsan/Toronto/IBM@IBMCA
Sent by: platform-update-dev-admin@xxxxxxxxxxx

21/04/2004 11:50 AM

Please respond to
platform-update-dev

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-update-dev] eclipse installation site types cleanup

The issue with links is backwards compatibility. 
I think the only problem with links is that they served two purposes: 
1. split the installation location (this is the good behavior)
2. have other products drop a .link file to their extension (not good)

I like the usage of links as a purely a product installation artifact,
to group features/plugins into meaningful chungs (eclipse install, product
install, third party add-ons, etc.) 
The links should be created by native installer when the product is first
installed, and other products should not change that. To add other extensions,
other installers should use the update operations (addSite, etc.) that
apply only to specific configurations. 

So, keeping links is good, as long as they're only used for the initial
product install, and they don't get changed by other native installers
(update manager itself never makes changes to the links).

-Dorian

Peter Manahan/Toronto/IBM@IBMCA
Sent by: platform-update-dev-admin@xxxxxxxxxxx

04/21/2004 10:55 AM

Please respond to
platform-update-dev

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-update-dev] eclipse installation site types cleanup

Meant to reply to this a while ago.

Re: [platform-update-dev] eclipse installation site types cleanup

• From: Dorian Birsan <birsan@xxxxxxxxxx>
• Date: Mon, 12 Apr 2004 17:59:56 -0400
• Delivered-to: platform-update-dev@xxxxxxxxxxx

---

Peter, still feeling strongly about added site via command not removable
via the UI? If the links are not deprecated, would you even have a need
for this command? 

---------------------------------------------------------------------------

For the first part I don't feel as strongly about not having it removable
via the UI. I prefer to just hide the UI :-) if possible. However looking
over the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=52820 indicates
it doesn't really solve that. Since both the manage configuration and search
for updates are both on the same dialog I can't really hide it correct?
I only wanted to hide the "Manage Configuration" not the whole
Software Updates menu. Although since we aren't using it to provide updates
to our product (we still use update manager just not directly in the product
) 3rd parties may want to update thier components.

About the need for the addsite command. 

The intent of the move all the config to the platform xml was that there
were too many places where it comes in. So I am not sure how using the
link files, beyond having them for backwards compatibility, jives with
that intent. 

I may be misinterpreting how it works but link files are always there.
 So if I have multiple configurations and I add a link file do all
the configurations get updated? If the answer is yes then having a link
files invalidates the centralization of the config information in the platform.xml.

For simplicity sake there should just be one way to update the platform.xml.
In all other cases the update api's modify the config. That should be the
only method allowed in order to keep it valid. The only way then to script
changes into the platform.xml is to use the eclipse update command line.

All I need to be able to do is "ensure" the ability to add a
site to a specific configuration.  That gives me the maximum flexibility
in control over what gets run and by whom. Using a link file I believe
is more restrictive as it targets a specific eclipse installation rather
than an eclipse configuration. 

So I would prefer never to have to use a link file again :-) and to keep
updates to the platform.xml consistent by having the eclipse Update API's
be the recommended method of modifying it. 



Thanks,

-----------------------------------
Peter Manahan
IBM Rational Tools
Common Install
------------------------------------
manahan@xxxxxxxxxx