[platform-update-dev] feature enable/disable support - and managing mult

[Pat McCarthy <patmc@xxxxxxxxxx>]

As we attempt to plan for how WSxx products, and ISVs, use the platform
in a coordinated way - we need to understand, and step through use
cases, using the planned function.

In general - how functional can we expect the next stable build to be
with respect to the complete update manager scenario?
Specific areas of interest would be:
- awareness of the installed platform as a set of managed features (when
will this be the default for a launched workbench)
- support for pre-req validation as part of feature install/config
- use of a feature enable/disable management dialog/perspective/view
- final version of branded launch point support

The ability to use one common platform as the base configured for use by
all subsequent product installs is our initial objective, but the
capabilities of install/update manager, as well as the way plugin
loading and what happens when there are conflicting plugin requirements,
seem to be making this a difficult goal.

One thought that keeps jumping up is to have a Workbench pkg (not
Eclipse, but the WSWB incarnation) pkg each feature in a different
\plugins directory.  The thought being that we might have a workbench
with these features:
B- base
J - jdt
P - pde
H - help (or may be part of base)
G - GEF
X - what ever is next.

A WSWB SDK launch point would be the base + links to J, P, H, G, and X.

A product, such as WSSD, which may not want JDT would have a launch
point that would be the base + links to P, H, G, and X.

The links would combine the separate feature-specific \plugins
directories.  This seems to be an option for easy configuration of
Workbench-based products that may need some, but not all, of the
features included in the Workbench.

This approach may not make sense if what I hear about user driven and/or
configurable mgmt of feature enablement is going to be available as part
of the update manger base.
- Is this expected function?
- Is this different than the base install/unconfigure support?
- If so - when might this be visible in a code drop?

Assuming this is planned function - Is the list of features available
defined by the active launch point (active configuration) or some other
approach??   (I'm assuming that features that have been formally
installed/configured would be visible of course, but am wondering if
features that already exist on the current system, which may have been
installed previously using an alternate launch point, would be visible
as features when the code was included in a 2nd launch point using a
link file reference. Guessing no - but it would be nice)

Now... if the update manager will enable this basic function as part of
some user accessible on/off configuration for feature access (similar to
the function provided with perspective>customize>action sets) - can the
settings used by the feature include/exclude be defaulted as part of a
launch point?
And - what is the scope of visibility the feature include/exclude dialog
would use? (what is available/visible in a link file + what has been
installed maybe??)

Would features that exist in the target of a link file references be
visible?  (My testing to date says no, but it might help with the shared
configuration objectives if they were visible).

And... with respect to an update site - the pattern is that the site.xml
identifies features and features identify which plugins they contain.

Once installed, as part of launch point 1, these same relationships
exist in that there is an \install\features directory with feature.xml
that identifies plugins in the \plugins directory.

It seemed (late one night) like it might be a good idea if we could
install/configure a feature that had already been written to the local
disk as part of a launch point 1 install, while using a launch point 2
configuration.  The thought was that the target install directory used
for the launch point 1 install would act as a site for launch point 2 -
the task left to perform being just a configuration.

I guess stated another way - what I'm trying to envision is how I get a
feature accessible in the workbench when I have multiple launch points
without installing the feature into a shared base platform \plugins
directory or adding link file entries for the install target to each
launch point.

Any/all comments welcome.