[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[platform-update-dev] Install Scenarios for Workbench-based Products
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: 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