[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Re: [platform-update-dev] Investigating some alternative update manager
|
Just for the record, I love features like poison :-). I too subscribe to
the assessment that 'there are wads and collections of wads'. What I was
taking an issue with was a seasonal push to force the 'wad collection
description' into another 'wad'. But in the future world that you
described, it seems that if one wants to do so, one will be able to. What
I see as a challenge though is to tie all these different ways of
provisioning bundles to Eclipse installations with some degree of
consistent user experience. But let's not get ahead of ourselves too much.
Regards,
Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4850
Jeff
McAffer/Ottawa/IB
M@IBMCA To
Sent by: "Eclipse Platform Update component
platform-update-d developers list."
ev-bounces@eclips <platform-update-dev@xxxxxxxxxxx>
e.org cc
Subject
09/15/2006 12:37 Re: Re: [platform-update-dev]
AM Investigating some alternative
update manager
Please respond to
"Eclipse Platform
Update component
developers list."
<platform-update-
dev@xxxxxxxxxxx>
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
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
