[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Install Scenarios for Workbench-based Products
|
Commented with <pm></pm>
Thanks,
_____________________________________
Peter Manahan
WSAD Linux Port Team
VisualAge for Java Release Lead
manahan@xxxxxxxxxx
_____________________________________
Pat
McCarthy/Raleigh/IBM@IBMUS To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@e Subject: [platform-update-dev] Install Scenarios for Workbench-based
clipse.org Products
01/02/2002 04:43 PM
Please respond to
platform-update-dev
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).
<pm>
The above should be a 1.0 only scenario. The branding article is only
partially correct for a 2.0 scenario (it assumes each product installs its
own version of the workbench and doesn't address the "workbench-enabled"
product as 1.0 doesn't support that). In 1.0 you can't really merge
products together without tramping all over the installs for them. (You
could of course just unzip everything but then that wouldn't really be a
product install).
For 2.0 there should be 1 copy of the workbench installed on the system and
it should have its own installation program. Products shipping with WSWB
should ship the installable version supplied as is.
</pm>
B. Supports a merged install where a standalone product is merged
with another standalone product.
<pm>
This doesn't really work in the 1.0 world. You can make it work of course
but it breaks all sorts of installation/support rules. If for instance an
add-on wanted to merge with WSAD and then plopped its files into WSAD's
file tree and hooked itself in, there is a very good chance that the
installation of WSAD just became an unsupported configuration (i.e problems
reported would have to reproduced without the add-on installed).
</pm>
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).
<pm>
1.0 is already broken. You will have multiple workbench's installed on the
system (1 for each product). May as well consider this whole topic a 2.0
discussion. All 2.0 products should be "Workbench-enabled".
</pm>
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.
<pm>
All products should be workbench-enabled. The workbench itself needs it own
installation with its own dependency checking. Three scenarios for install
are:
1. Product is installed on its own (i.e. WebSphere Studio Application
Developer)
2. Product requires another product(s) (i.e. An add-on tool like an EJB
validator or something for WSAD which requires WSAD to be installed)
3. A generalization of 1 and 2 where products are merged together. So a
launch of the workbench would have all the products available installed to
it available.
Since products should use native installers for multiple reasons including
dependency checking and support issues etc. And eclipse needs to know
about and have control of its configuration there is a way to get the best
of both worlds according to the update spec for 2.0.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-update-home/doc/working/eclipse_install_R2_0_draft.html
Using windows as an example. There needs to be an implementation of the
Feature Install (part of the install framework) that uses Windows Installer
as the install mechanism. Then the install of a product like WSAD would go
like so.
1. User launches the WSAD install
2. WSAD install launches the WSWB install which checks to see if it already
installed and if not installs itself.
3. The WSAD install runs a headless application which uses the workbench to
update itself with WSAD using the install framework and a Windows Installer
implementation of IFeature (which can then do all the necessary things
needed for an install for windows).
</pm>
---
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)
<pm>
OS installation programs do this for you. The only reason for something
like a registry key is for systems where this function isn't available.
Since the workbench doesn't ship on those OS's it isn't a problem. On
Windows (Windows Installer) on Linux (RPM).
</pm>
How multiple products should support install/uninstall so as to not
disable other merged products
<pm>
As long as products use the update/configuration support being provided by
eclipse for 2.0. With the installation methods above it should work quite
smoothly.
Although a couple of no-nos should be expressly forbidden.
1. Any files installed by a product install should not overwrite/modify
files in another product's install tree.
2. File can be installed into another product's install tree as long a
a. They do not overwrite files
b. The install is a complete dependent of the main product's install.
This basically means that inorder for the first product to uninstall all
dependent installs must be run first.
3. Configuration modification needs to be done outside the install tree
which is read-only. (This is a Linux requirement [should be in /etc and
maybe in users homedir] but should be done on windows as well; especially
if you have multiple users of a product installed on 1 machine).
</pm>
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
