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!
Toni
Jeff McAffer schrieb:
Toni Menzel <[EMAIL PROTECTED]> 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
http://www.tonit.com
mailto:[EMAIL PROTECTED]
