If you need to connect to existing Eclipse extension points, such as writing Eclipse plugins which must integrate into the existing Eclipse plugins, then you will probably need to use the Eclipse extension registry model.
If you are doing anything else, use OSGi Services via the OSGi Declarative Service model. OSGi services are bound by the bundle lifecycle which means a bundle must be started to register or use services and when a bundle stops, it releases any registered or used services (the mechanics of this are nicely handled by OSGi Declarative Services).
The Eclipse extension model predates the adoption of OSGi by Eclipse and has an undesirable life cycle binding. Eclipse extensions are bound to the resolved state (when a bundles class loading dependencies are met and the bundle can have a class loader) which means starting and stopping a bundle have no bearing on the bundle's use of extensions. This can be very awkward especially during development. In Bndtools (tooling for OSGi bundle development), we have Eclipse plugins and must use Eclipse extension points to integrate with the IDE, but due to the life cycle binding of Eclipse extensions, we are moving to a facade model when we have a bundle which uses Eclipse extension and delegates to another bundle using OSGi services. This allows use to easily replace the bundle proving OSGi services while the facade bundle is statically bound to the Eclipse extension point registry.
--
BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788 hargrave@xxxxxxxxxx
----- Original message ----- From: "Thomas Watson" <tjwatson@xxxxxxxxxx> Sent by: "equinox-dev" <equinox-dev-bounces@xxxxxxxxxxx> To: equinox-dev@xxxxxxxxxxx Cc: Subject: [EXTERNAL] Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xml Date: Wed, Sep 29, 2021 09:01
That is a bit of a dramatic statement that can open a can of worms. The extension registry and the Eclipse platform model with its many extension points does what it does very well. If you are developing bundles that plugin to the Eclipse platform do not "feel bad" about using the right technology. Many times that will be writing an extension and defining a plugin.xml. If you are not plugging into the Eclipse platform then use the technology that suits your needs. I agree the OSGi service registry and actually the use of Declarative Services is a very good mechanism that has many advantages.
Tom
----- Original message ----- From: "Jürgen Albert" <j.albert@xxxxxxxxxxxxxxxxxx> Sent by: "equinox-dev" <equinox-dev-bounces@xxxxxxxxxxx> To: equinox-dev@xxxxxxxxxxx Cc: Subject: [EXTERNAL] Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xml Date: Wed, Sep 29, 2021 7:45 AM
Yes, the plugin.xml is a leftover of the early days. OSGi offers the far superior mechanism of Declarative Services. I'd strongly recommend to avoid the old extensions wherever possible.
Regards,
Jürgen.
Am 29/09/2021 um 14:23 schrieb Mickael Istria:
Right, plugin.xml is an Eclipse-specific format for extensibility, which is not part of OSGi specification. Support for this "extension registry" of plugin.xml files is part of the org.eclipse.equinox.registry bundle. I believe it's totally possible for Equinox to work comforming to OSGi spec without this bundle.