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

[celek@xxxxxxxxxx]

Hi Pat,

I tried to answer even if I do not know so others can add to our comments



[snip]
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)
<CE> I do not know, others may ?</CE>

- support for pre-req validation as part of feature install/config
<CE> I do not know, others may </CE>

- use of a feature enable/disable management dialog/perspective/view
<CE> should be ok to use, open bug if not </CE>

- final version of branded launch point support
<CE> don't know , sorry</CE>

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.
<CE> please elaborate in concrete terms </CE>

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.
<CE> why in different directory, you may have a good reason (cf previous
question) and it will probably help others to understand the path you took
to get to this point, no ? </CE>

[snip]

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.
<CE> can you elaborate ? The user will be able to configure/unconfigure
features from the UI </CE>

- Is this expected function?
- Is this different than the base install/unconfigure support?
- If so - when might this be visible in a code drop?

<CE> I may not understand your concern clearly, sorry, but another view
(correct me if I am wrong) would be to have one feature - the supported
product - , then to have update for the component, so user can 'update' the
'product' and 'add' new 'features' (which are also part of the product but
hidden). In that situation, the user should see the product configured as
well as, let's say, the new version of the JDT. We may envision a UI light
that will tell the user if S/He running in a supported mode, based on the
comparison of the 'plugin.xml require' and the Loaded PluginRegistry </CE>

Assuming this is planned function - Is the list of features available
defined by the active launch point (active configuration) or some other
approach??
<CE> I believe we should have explained that in a spec doc, sorry if we
didn't do it, or didn't do it properly. The 'launch point' is a list of
'site' and 'plugins' that are either to be included or excluded based on
teh 'policy' of the site. This determine the runtime behavior. The
Install/Update compares this 'launch point' with its own metadata to
determine if a 'reconciliation' is necessary (something has changed on the
file system). If no reconciliation is necessary, Install/Update uses its
own metadata. If a reconciliation with the File System is necessary, the
Install/Update will 'discover' the features if #1 the site lets you
discover them (EXCLUDE policy) #2 if proper feature metadata (feature.xml)
is found in the appropriate place (install/features/<name of feature>).
Does that answer your question ? If this is not teh behavior you want or if
you experience a bug (oh my ! ;-) please open a bug </CE>

 (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)
<CE> off the top of my head it should based on reconciliation paradigm,
please provide testcase </CE>

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?
<CE> once again I may have missed your point but I believe the Site is
responsible for setting such policy, no ? <?CE>

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??)
<CE> sorry, can you elaborate ? </CE>

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).
<CE> check the policy of the site and provide testcase </CE>

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.
<CE> the initial goal was that every site is potentially a site you can
install from. This is probably not supported, but I bet you if you create a
proper Site.xml , you can install from your existing Eclipse directory
</CE>

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.
<CE> yep </CE>

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.
<CE> the problem is 'how to make other launch point aware of my change' #1
if this is a site you will need to modify the platform.cfg and thus use the
API #2 if the launch poitn already points to the Site, discovery should
occur </CE>