What you're basically arguing for is the extender pattern. You're right that not everything is best represented as a Java object implementing a service interface. Some contributions are best offered as static or declarative resources in a bundle.
The Eclipse Extension Registry is essentially just an instance of the more general extender pattern. DS and Blueprint are examples as well. You can implement the extender pattern yourself pretty easily with portable OSGi APIs, such as BundleTracker
. Also make sure you take full advantage of the Provide-
and Require-Capability
headers, to make sure that your extender actually gets picked up and installed by a resolver.
One word of warning about Eclipse Extensions... while there is a lot to like about them, they get the lifecycle all wrong. The extension registry will consume bundles in the RESOLVED state, but this means that you have no control over which bundles are consumed and which aren't. Most extenders should only consume STARTING or ACTIVE bundles, since the active state can actually be controlled.
UPDATE
Incidentally the Eclipse extension registry is implemented with a couple of bundles, and as far as I'm aware they work on any standard OSGi framework, i.e. not just Equinox. So there is nothing "non-OSGi" about them... they are just an additional layer on top of OSGi. If you really like them, then please continue using them! The reason most people in the OSGi community don't use them, I believe, is that they are not really worth bothering with. Once you get used to the proper way to work with services and extenders, you will probably find Eclipse-isms less attractive.