Re: Re: [platform-update-dev] Investigating some alternative update mana

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Alex, thanks for taking the time to put down all that
detail.  I'm not at all opposed to what you describe.  I do have
some observations

- bundle dependencies as expressed in the manifest.mf
are not enough for provisioning.  The help system is illustrative
here.  To add a functioning Help system to an Eclipse configuration
you need to add about 7 plugins.  However, if you grab the root plugin
(org.eclipse.help.ui or whatever) and follow the expressed dependency chain
you would miss org.eclipse.tomcat and org.eclipse.help.webapp (or some
such).  This is because Tomcat extends Help with an app server and
webapp extends Tomcat with the help web app.  (the details may be
off but you get the idea).  The connection here is via the extension
registry.  The Help function does not depend on Tomcat but having
a functioning help system depends on having a suitable app server plugged
into the help system.  Neither producer here (Help or tomcat) is in
a position to express this dependency as it is a logical or selective dependency.
 A similar scenario with OSGi services is left as an exercise for
the reader.

- similarly, some logical groupings consist of disparate
functional pieces. I might want CDT and JDT but have no plugin that depends
on both directly.

- groupings that are logical must, in general, be
crafted by developers.  They cannot be generated or discovered automatically.

- Features include a notion of "selection".
 Take a look at the SWT fragment entries in the RCP feature.  You
will see a mess of things like os="win32" ws="win32"
etc.  These are selectors that basically say "this line in the
feature.xml is valid if the installation context matches these criteria".
 Currently the set of selectors is pretty limited but there are good
usecases for extending this and allowing arbitrary selection.

- OBR does not address the all problems solved by
features. 

- some aspects of what you discuss are treated in
the OSGi Mobile Expert Group (MEG) Deployment Admin service.  You
might want to check out the relevant sections of MEG spec at http://osgi.org.
 Note also that Simon Kaegi has been working on a deployment admin
implementation in the Equinox incubator.  Note still furhter that
I believe there to be basic issues with elements of deployment admin but
it is an interesting point of view.

- the .eclipseextension files, eclipse dirs, ... etc.
are goofy but have nothing to do with features, atoms, bundles, ...  We
could simply delete the check with no loss of generality.

Having said all that, there are some excellent usecases/motivations
for simplifying things and increasing consistency in the implementation.
 Personally I'd like to step back from many of these details and get
to a place where you can have Atom feeds, Dejan can have features (cause
he loves them so), MEG-heads can have deployment packages, ... all on the
same infrastructure.  In the end there are wads and collections of
wads.  The rest is syntax and policy (just for Pascal ;-)

Jeff