[platform-update-dev] Install Scenarios for Workbench-based Products

[Pat McCarthy <patmc@xxxxxxxxxx>]

The install scenarios described below are offered up as an attempt to help
the conversation regarding how install/update support should be enabled
in the Workbench platform. If we can agree on the scenarios that should
be supported, and then how each process should be implemented (as part
of a product install process or via function in the Workbench platform)
we should be able to make some decisions on what function is provided by
the platform in a 2.0 time frame and what the responsibilities are for
Workbench-based products.

As a start I'd be looking for comments on terminology (Workbench-packaged and Workbench-enabled), scenarios, need for dependency checking during product installation, and scenario issues that have not been addressed.
---

Installing products based on the Workbench has some unique considerations in that the built-in extensibility of the workbench encourages the use of a rich combination of tools and technologies from multiple providers that might all share a single installed image of the Workbench platform.

These common install/uninstall scenarios are described for the Workbench platform:
 

> 1. (Workbench-packaged) Installing/uninstalling a product that
> based on the Workbench platform.  A Workbench-packaged product includes
> the Workbench in the installable code base (packaged per the branding article
> on Eclipse.org).  In this scenario the Workbench-packaged product:

> > A. Supports a standalone install where the Workbench platform
> > is installed as part of the product stack (for example, IBM's WebSphere
> > Application Developer).

> > B. Supports a merged install where a standalone product is
> > merged with another standalone product.
> In this scenario there are no direct dependencies between the products
> but they share a common Workbench platform as installed by the first standalone
> (merge target) product.

> ReviewNote: The branding article suggests that products hide
> \eclipse down one dir level.  This, and the merged install not supporting
> 2nd level branding (in a 1.0 timeframe) may make this difficult for some
> products to accept).

> 2. (Workbench-enabled) Installing/uninstalling an add-on product
> (set of plug-ins) on top of an existing packaged product that is based
> on the Workbench.  The installable code for a Workbench-enabled product
> does not include the Workbench platform.  In this scenario the Workbench-enabled
> product:

> > A. May be a general purpose tool that does not have a direct
> > prerequisite on any code (Workbench-packaged or Workbench-enabled) beyond
> > the Workbench platform.

> > B. May have a prerequisite on another Workbench-packaged product
> > (typically a standalone product or participant in a merged product install).

> Essentially the process is to install the add-on product plug-ins
> into the “eclipse/plugins” subdirectory of an installed workbench instance.
---
To support the actual implementation of installable product there is
another level of detail required.  Specifics that still need to be
identified include:

• How the Workbench platform identifies itself as being installed (such as a registry key entry for a Windows system)
• How multiple products should support install/uninstall so as to not disable other merged products

Thoughts on these and other issues have been developed based on how products
should be using the 1.0 version of the Workbench platform. These details
can be shared here if you think it appropriate for this 2.0 level discussion.

Comments welcome.

Regards,

Pat McCarthy, OTI-RTP
patmc@xxxxxxxxxx