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

[klicnik@xxxxxxxxxx]

Pat, I will try to answer, but I am not sure I understand all the question 
(asked and implied) and all the scenarios you are trying to cover. I will 
break the conversation into several topic areas (so we can keep things 
clean).  I will also try to indicate what should work in current builds 
(modulo bugs), and what does not work yet.

Topic 1: plugin-path, configurations, launch points

In Eclipse R1.0 we had the ability to explicitly control which plugins got 
executed as part of running Eclipse. If you specified -plugins argument 
and pointed it at a file containing the list of plugins to run, that is 
what Eclipse came up with (except for core.boot, core.runtime, xerces 
which required special handling). If you did not specify the -plugins 
argument, the platform assumed you wanted to come up with all plugins it 
found relative to core.boot.

In Eclipse 2.0 we have evolved the plugin-path file to become the 
configuration file. However, its intent is still the same ... allow 
control of which plugins actually execute. In 2.0 it is specified as 
-configuration <url> on startup. If you do not specify this argument, the 
platform pretty much behaves like in R1.0. The base support for 
-configuration and migration support for -plugins should work in current 
builds.

The format of the saved configuration file is not documented ... it is not 
intended as API. The problem is that we do not provide a separate 
"configuration file" editor either, and such editor is not in the 2.0 
plan. You can create a configuration file programatically (see 
BootLoader.getPlatformConfiguration(null) and methods on the returned 
IPlatformConfiguration object (incl. save(URL) ... see the javadoc for 
details). And perhaps someone will write and contribute an editor. In the 
meantime you are stuck editing the files, but their format could still 
change.

The basic element of a configuration is a "site". This is basically just a 
URL of a base directory that is used as a source of plug-ins. The exact 
processing depends on the policy associated with the site. By default, 
sites are created with an "exclude" policy. An "exclude" policy means that 
the platform will attempt to use all plugins found relative to the base 
directory, EXCEPT those explicitly listed. In all your default examples 
you were using an "exclude" policy without an exclusion list, so 
essentially the platform would use whatever it found on the site. The 
other possible policy is an "include" policy. This indicates that only 
those plugins explicitly specified on the inclusion list will be 
considered, regardless what other plugins may reside on the site. This 
should all work (modulo bugs).

The Update Manager support maintains the configuration information based 
on what features are installed and configured. In the current builds, 
there is no capability to set a policy on a site (all sites are created 
with "exclude" policy). There is a defect to fix this (13387). The Update 
Manager is the only intended UI that causes changes to the live 
configuration information. 

The concept of a link is just a mechanism to associate additional sites 
with the configuration without the need to edit the configuration file. 
Its primary intent was to accommodate native installers that establish 
additional plugin directories (additional "sites"). Links result in site 
entries with "exclude" policy and no exclusion list (ie. all plugins 
located relative to the link root are considered).

The notion of a "launch point" is simply a combination of the launch 
executable with some configuration file (defining what you are launching). 
The separate launch points and corresponding configuration files are 
independent of each other in the sense that configuration actions taken in 
one launched instance of eclipse does not (immediately) modify the 
information in another launch point. Note, however, that if two launch 
points reference the same site using an "exclude" policy, changes made to 
the site by one launched eclipse instance will be detected when the other 
instance in launched. The second launched instance will take the 
"appropriate" action (see Topic 3) depending on the change.

There has been a requirement raised in this mailing list (by Steve 
Francisco) to allow "configuration inheritance". I would describe this 
capability as a way of chaining configurations, so that one configuration 
(eg. on many clients) could reference a separately administered 
configuration (eg. common configuration administered by tool 
administrator). This way changes to the common configuration would be 
"automagically" reflected in all launched eclipse instances referencing 
it. Although this would be a very useful function, at this point it does 
not look like it will make the 2.0 dates. If something like this would 
solve a lot of problem scenarios, let us know and we could take a look at 
it again to see what could be done.

Topic 2: features

Features are basically annotated plugin manifests. They are not an eclipse 
runtime concept. They are used by the Update Manager support do decide 
what plugins to download and configure. No more, no less. Features do not 
play any significant role during eclipse execution (modulo selecting the 
"branding" information). 

The Update Manager is the only UI that manipulates features (I am not sure 
where you got the idea we'll have something like enable/ disable action 
sets). You can install, unconfigure, (re) configure and remove features 
using the Update Manager UI. This function should be working now (modulo 
bugs). The result of these actions is that the configuration file of the 
currently executing eclipse instance is updated to reflect the actions.

You asked about installing from the current installation. You can set 
things up so that an installed site is used as an update site (ie. have 
user B install from what user A is executing). However, this just confuses 
the things. The simpler thing to do is for both users (using separate 
launch points) to point their eclipse to the update site and request the 
feature be installed. If both configurations specify the same installation 
site as the target, one of the users will betect the required plugins are 
already installed, and the "install" action will basically amount to a 
feature configuration action (no additional download, copy of files). So 
the result is the same and the user only needs to deal with one scenario 
... always go to an update site for new features and updates. All of this 
(as well as signature verification on downloads) should work now (modulo 
bugs).

Topic 3: runtime implications

There are a number of miscellaneous runtime considerations that are part 
of this story:

(1) picking the correct core.boot to execute. This support is not in yet, 
will be in M6. At present, the platform will use the core.boot it finds 
relative to startup.jar, or you have to specify -boot (this should work)

(2) picking the correct core.runtime, xerces. These (plus core.boot) are 
the pseudo-plugins that need to run before the platform knows anything 
about plugins. This support is not completely in yet, will be in M6. At 
present, the platform picks the "best match" for these from the computed 
plugin path

(3) selecting the primary feature using -feature (determines "branding" 
information). This support is partially in, but from your point of view 
does not do what you need. This is one of the properties set in the 
configuration file. The code to use it is there. The code that sets it is 
not. This also impacts ability to update the splash screen (also targeted 
for M6).

(4) for sites that use "exclude" policy, the runtime attempts to detect 
changes in the install since the last startup. If only plugin changes are 
detected (no feature changes) then the new plugins are used for startup. 
If feature changes are detected, the startup actually launches an update 
reconciler application that attempts to reconcile the detected changes 
with the current configuration.  When it completes the reconciliation, it 
requests that the platform be restarted with the original startup 
arguments (but now reconciled configuration). This support is mostly in 
now (modulo bugs) ... the part that is not in is the restarting bit 
(should be in shortly after M5 (possibly next weeks integration build)). 

(5) the configuration support determines which list of plugins will be 
considered by the platform. The platform itself determines which plugins 
are actually used. This behavior is the same as was in R1.0 (no changes, 
few bugs were fixed). Basically the platform uses the <import> elements 
from the plugin.xml to pick the "best" match for each dependency. You can 
specify which plugin you need, at what version and what matching rule to 
use. The platform considers these constraints and produces the "best 
match". If some of the dependencies cannot be resolved, the plugins with 
the unresolved dependency are disabled (recursively up the chain). In some 
cases the platform allows multiple versions of the same plugin to be used 
concurrently. Last time I looked the rule for this was that the target 
plugin was only allowed to contribute <library> elements (no extensions, 
no extension points).

That's it .... hope this is of some help. I would be interested is 
specifically evolving the scenarios you, or anyone else out there, need to 
support to make sure we have what you need.