OSGi-Friendly Plugins

[peblair]

cc: @c0d3d
easy-plugins works well within a single-classloader environment, but there are challenges involved with running things across OSGi boundaries. In particular, the *Registry classes are only able to discover services via the ServiceLoader API, meaning that the only way of wiring things up in a cross-bundle scenario is via the OSGi service mediator (in theory). Worse, this requires users to break the easy-plugins abstraction by specifying the auto-generated interface in provider bundles' OSGi manifests. To overcome these issues, we should provide better support for wiring up services. Some ideas:

• Ability to manually register services with registries (Solves issue 1 but not issue 2). In combination with an OSGi service tracker, this would remove the need for the service mediator.
• Automatically add the auto-generated service to the OSGi manifest during compilation (which should make the service mediator "just work"...?)
• Add a method to the registry which returns a service tracker for its associated interface. This has the following benefits: (a) it is a "robust" abstraction which still hides many details, (b) it can be implemented by a plugin.

Additionally, there may be good solutions not listed here.

[c0d3d]

My vote is we try for option 3.
If that fails, option 2.
If that fails, option 1.

[peblair]

Agreed. Note also that we could maybe even cobble together a bndtools plugin, despite the relative lack of documentation. See this interface which makes use of this class. Here is an example of an abstract class which implements a large part of a BND plugin.