[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Install Scenarios for Workbench-based Products
|
Rather than mark up the original anymore I'll talk about the specific
parts.
1. Regarding the installation into the workbench directory. I see I wasn't
very clear and seem to waffle and to some extent I was waffling :)
Historically with VAJ in particular but also with other products
installation of one product into another product's directory tree has
caused problems. Mainly with uninstallation and migration/upgrades failing
because the other product installed into the directory structure and the
installation mechanism's didn't know about it. It came down to a series of
manual steps needed to fix the problem each time. This came with a volume
of support calls.
For eclipse based products and WSWB specifically the default implementation
of the feature installer is basically unjar. So what is sure to happen is
someone's plugin gets packaged as a feature and uses the default
implementation of the feature install. This will then get dumped into the
plugins directory and as a result WSWB "install" will be corrupted. This is
the situation I would rather avoid. There are 2 ways to avoid it.
a. Install the feature into its own directory tree. (This should be done
for large features such as WSAD anyway. It eases maintenance)
b. If the feature uses the OS install implementation of the feature
installer and prereqs then Workbench correctly then it will not corrupt the
installation of WSWB even though it sits in the WSWB directory structure.
2. Product becoming unsupported due to installation of 3rd party feature.
I mentioned the product becoming unsupported in one case and that is true
from a certain perspective. If the bug cannot be reproduced without the
add-on present then it is possible for the product to be come unsupported
in that sense when the add-on is present. I was thinking as I wrote that
bit about those really bad add-ons that replace the base code with their
own implementation. And about the breakages caused because other pieces of
the product were dependent on the piece that got overwritten. It was this I
was trying to point out and not doing a very good job at :)
Which means there needs to be a well-known definition of how plugins are
versioned. It seems it isn't generally known that the name of a plugin's
directory is a convenience and could be called anything. This would allow
multiple versions of the plugins to work together as different plugins
required different versions.
ie. com.ibm.mby.mycoolplugin1_0
com.ibm.mby.mycoolplugin2_0
However eclipse itself would have to start doing this with their own
plugins and they haven't as of yet. When they replaced Ant for example they
just dropped a new one in instead of adding a new plugin into 2.0 and
staging the old one out. So a migration of 1.0 eclipse to 2.0 eclipse will
require an overwrite of the org.eclipse.ant.core directory and any plugins
that needed the 1.0 version would be broken. (This is assuming plugins
from 1.0 would run with 2.0 though and it looks like that scenario isn't
likely to happen).
3. Update specification notes regarding the native installer basically
being ignored.
This is true and false :) If you use a "pure" native installer to install
plugins then it is true they will be basically ignored. I had an extreme
problem with this myself as it made the update/configuration mechanism's
seemingly useless for products.
However it seems that reading between the lines was needed. In an offline
discussion it was pointed out to me that the feature installation mechanism
was a framework. The default implementation of which was to unjar the
feature. So in essence what we can and what WSAD at least will have to do
is to create a feature installer implementation for Windows Installer and
rpm. The the update mechanism can be used and the native installs become
first class rather than coach .
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: Re: [platform-update-dev] Install Scenarios for Workbench-based
clipse.org Products
01/07/2002 06:53 PM
Please respond to
platform-update-dev
I guess I'll be pfm if you are pm.... see below.
Pat McCarthy -- Eclipse Platform Enablement (3ECA)
-- OTI - RTP, NC
-- (919 254-6231 / 8-444-6231 -- FAX
8-444-4183)
-- Internet: PatMc@xxxxxxxxxx
-- Lotus: Pat McCarthy/Raleigh/IBM
Peter
Manahan/Toronto/IBM@IBMCA To:
platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@e Subject: Re:
[platform-update-dev] Install Scenarios for
clipse.org Workbench-based
Products
01/06/2002 10:47 AM
Please respond to
platform-update-dev
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>
<pfm>
Agreed.
To me 1.A could also be having a product install start by kicking off (or
identifying a pre-req of) a formalized WSWB install (where the registry key
is defined). The product would then install logically on top of the WSWB
Workbench platform(maybe not physically - that is, not using the same
\plugins dir).
This would be value add provided by an installable WSWB as I'm not aware of
a plan to have an installable image of the Eclipse Workbench platform.
The 1.0 implementation guidance for these scenarios clears up things a bit
- I'll add this additional detail as a comment on the root entry for this
thread later.
</pfm>
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>
<pfm>
Understand the concern and I don't disagree.
The goal is one of trying to enable the promise. We have promised support
for integration of multiple products that use the same Workbench platform.
If we don't allow/support this integration with any of the delivered
product stacks - the promise is broken - the value add to the buying
customer lost.
We state this as a scenario as it is a valid objective. One that is
probably easier to implement on Windows as opposed to Linux, if we discount
your point regarding maintenance (as there isn't a file system on Windows).
One direct response to your support scenario problem - if the products are
independent, and only merged to achieve integration for resource management
(use same workspace for tool A and B resources), or only integrate via
read/write of common resources (one publishes Java source from some model,
the other reads/uses/reworks the source), and/or only exist side-by-side in
the same Workbench instance... why should there be a support problem? Are
we not also selling the idea that the platform makes the products
independent even while integrated in the same platform instance?? If
product A actually built on top of product B (action contributions to the
other products views, use of published API extension points...) then a
problem with product A should be a supported problem - right?
</pfm>
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>
<pfm>
Agreed in that we don't really expect anyone to actually support scenario
1.B in a V1.0 timeframe. To many local product packaging decisions were
made before install guidance was formalized.
</pfm>
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>
<pfm>
> All products should be workbench-enabled.
The difference I see in Workbench-packaged and Workbench-enabled is that a
packaged product is responsible for the installation of the Workbench if it
does not exist on the target system.
A product in your scenario 2 (Product requires another product(s)) should
not include the Workbench - no reason to do so. It needs to be able to
ensure it's prerequisites are installed - that is all.
I'd agree with your subsequent description of how the Feature Install
mechanism should work. But my read of the current design doc says products
that install in their own dir structure and use links to integrate into the
shared Workbench instance become unmanaged components/plugins.
? Do we not want a product that installs on top of an existing Workbench
instance using a private plugin dir to be able to use the update mechanism
to find service?
</pfm>
---
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>
<pfm>May be part of the reason we need an installable instance of the WSWB
Workbench platform</pfm>
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>
<pfm>
>2. File can be installed into another product's install tree as long a
> a. They do not overwrite files
? I thought an issue describe earlier was that you did not want to have to
copy product plugins into the plugins dir of the Workbench instance (the
goal of trying to use plugin-path or its equivalent)?
</pfm>
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
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
