| OSGI Services [message #46524] |
Tue, 01 February 2005 05:28  |
Eclipse User |
|
|
|
Originally posted by: rschmaud.NO.SPAM.de.ibm.com
Hi,
What are the plans for supporting OSGi Services in Eclipse 3.1 or future
releases?
If I understand it right, there are currently two ways of specifying the
runtime dependencies between plugins - plugin.xml and manifest.mf. And
there are two ways of using functionality from other Plugins - extension
points and OSGi Services.
Using the extension point and plugin.xml way, the dependencies between
plugins are hard-coded, a plugin A requires a plugin B and not the
functionality or specific Java Classes or ressources. The same is true
for extension points, Plugin A depends on a specific extension point of
Plugin B. So there is no way to replace Plugin B with another Plugin
which provides the same functionality and the same extension point.
I think this would be possible with osgi, a bundle can register a
service at the registry and another bundle can get this service from the
registry without having explicit dependency on the providing bundle.
They only have to share the interface of the service (which could be
provided by a third bundle).
So the only way to get loosely coupled components in eclipse is using
the OSGi Services. But I have not seen a way to register a service
without loading a plugin wich is in conflict with lazy loading.
Are there plans to migrate the extension point mechanism to the OSGI
service model or to support registring services in the manifest.mf or
the plugin.xml file?
Kind Regards
Ralf
|
|
|
|
|
|
| Re: OSGI Services [message #46844 is a reply to message #46524] |
Sun, 13 February 2005 23:37  |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
Ralf,
The extension model and the service model are complementary. It is not
possible to, in general, map one onto the other. For sure there are some
things in Eclipse that would be better off as services and I expect that
over time equivalents will be made available. I doubt however that there
will be a concerted effort to do this accross the board.
As for the (lack of ) laziness of services, OSGi R4 may contain some support
in that area. It is unclear if Eclipse will include that support.
Jeff
p.s., side notes: The manifest.mf vs plugin.xml thing is just a syntax
issue. We freely convert the execution portions of the plugin.xml to
manifest.mf. Going forward Eclipse will have only extension markup in
plugin.xml and all plugins will ship with manifest.mf files. This doesn't
actually get you anything until people start using Import-Package and
restructuring their plugins to separate out API.
p.p.s., the hardcoded dependencies were done on purpose. There is no right
answer here as both approaches have benefits and drawbacks. The pressures
pushing us that way 5 years ago were from product teams that explicitly did
not want to allow people to substitute in any old implementation of
something. They want to express the dependencies based on what they are
shipping. This produces a more rigid structure but ultimately one that is
servicable and maintainable. Going the other way allows more flexibility in
configurations etc. Poison or desert as you choose...
"Ralf Schmauder" <rschmaud@NO.SPAM.de.ibm.com> wrote in message
news:ctnlk2$j7s$1@www.eclipse.org...
> Hi,
>
> What are the plans for supporting OSGi Services in Eclipse 3.1 or future
> releases?
>
> If I understand it right, there are currently two ways of specifying the
> runtime dependencies between plugins - plugin.xml and manifest.mf. And
> there are two ways of using functionality from other Plugins - extension
> points and OSGi Services.
>
> Using the extension point and plugin.xml way, the dependencies between
> plugins are hard-coded, a plugin A requires a plugin B and not the
> functionality or specific Java Classes or ressources. The same is true
> for extension points, Plugin A depends on a specific extension point of
> Plugin B. So there is no way to replace Plugin B with another Plugin
> which provides the same functionality and the same extension point.
>
> I think this would be possible with osgi, a bundle can register a
> service at the registry and another bundle can get this service from the
> registry without having explicit dependency on the providing bundle.
> They only have to share the interface of the service (which could be
> provided by a third bundle).
>
> So the only way to get loosely coupled components in eclipse is using
> the OSGi Services. But I have not seen a way to register a service
> without loading a plugin wich is in conflict with lazy loading.
>
> Are there plans to migrate the extension point mechanism to the OSGI
> service model or to support registring services in the manifest.mf or
> the plugin.xml file?
>
> Kind Regards
> Ralf
|
|
|
Powered by
FUDForum. Page generated in 0.09750 seconds
Home