felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <tonimen...@gmx.de>
Subject Re: are Extension- headers proprietary ?
Date Thu, 16 Nov 2006 16:26:33 GMT
About the Export-Service Header:
it seems that has it's origin in the old maven plugin "maven-osgi-plugin".
Bundles generated with that (and so are some systembundles) instead of 
the new one ("maven-bundle-plugin") have some more entries and some 
currious ones like that one.

The thing is that the PDE has support for another layer (I think it's a 
plattform like everything made @eclipse ;-)  on top of osgi dealing with 
extensions and extensionpoints.
But that stuff goes to plugin.xml and denotes to that layer/plattform 
specific to the Eclipse.
So that has nothing todo with the headers described above. (I just got 
too much new suff mixed up in my head, ..)

@Jeff: is there some more abstract description about that 
extension/extension-point mechanism used in RCP but without dealing with 
the "C" too much (so something like Rich-Plattform) ?
(I've seen and used that things in a very small sample RCP app, without 
hesitating about osgi back then). So I want to figure out if it makes 
sense from the osgi perspective too.
Thanks for the very good feedback!


Jeff McAffer schrieb:
> Toni Menzel <tonimenzel@gmx.de> wrote on 11/15/2006 12:14:53 PM:
>> I'm just playing with some sample bundles using eclipse for tooling 
> support.
>> There, looking at the headers of examples/dictonaryservice, there are 
>> some lines beginning with for example Extension-Name.
> I'm not familiar with that header.  In general headers that we have added 
> are prefixed with Eclipse- (e.g., Eclipse-PlatformFilter).  Perhaps that 
> one is just something someone put in an example?  Similarly, additional 
> directives are prefixed with "x-" (e.g., x-internal). 
>> I think this is a (proprietary) extension in equinox or the 
>> Eclipse-Plattform itself.
>> As equinox being the "reference implementation" (I heard this at a 
>> tutorial by Jeff McAffer at the JAOO Conference), is this a close to 
>> OSGi (maybe next gen) stuff or just for more comfortable eclipse 
> tooling?
> In some cases Equinox specific headers/directives are being debated as 
> part of the next versions of the OSGi spec but their inclusion in the 
> final spec or the final form is by no means represented by the Equinox 
> code base.  As for the reference impl point, Equinox was available as an 
> open, accessible and maintained R4 implementation when the R4 spec was 
> completed.  It made sense to use it as a reference implementation.  Going 
> forward I hope that there are other implementations that also fill that 
> role.
> I'll have to know more about the specific headers (perhaps the whole 
> manifest) and the situation before commenting on the use/value of the 
> headers.  Only one header springs to mind as being for our tooling 
> (Eclipse-ExtensibleAPI) and it is only needed in very fringe (important 
> but fringe) cases.
>> btw: is there an easier way using eclipse as bundle development 
>> plattform for felix itself and take benefit from the rich tooling 
>> support without having to:
>> 1. convert each project to be a "plugin" (that's not that bad)
>> 2. have to sync (!!) manifest files manually from the pom.xml ? (that is 
>> what the maven-plugin does)
>> Even worse, I have to keep that stuff in sync manually.. :-(
> The challenge here has been discussed repeatedly and at length in this and 
> other forums.  Maven and PDE (Eclipse's Plugin development environment) 
> both want to be on top.  The current techniques are a bridging story at 
> best.  I'd like to avoid opening the discussion again but will say that I 
> would very much like to see a convergence in the tooling area.  There has 
> been some very modest progress but there is still a ways to go.  For now 
> the issues you see are because you are living between the two worlds.
> Perhaps others on this list can describe workflows that could improve 
> Toni's life?
> Jeff

Toni Menzel

View raw message