Declarative Services - Dependency Injection OSGi Style

An overview of Declarative Services, most of it already known to us but included some interesting tips. XML descriptors are loaded at application start and bundles are lazily loaded. MANIFEST.MF header Service-Component can use wildcards if XML uses version 1.1 schema but not if using 1.0. Some description of low-level API such as ComponentContext but its use is discouraged. Four types of components were identified:

• Non-service component - can interact with services but not retrieved
• Service - the usual case
• ServiceFactory - can instantiate multiple copies of a service
• ComponentFactory - used by infrastructure

An overview of component attributes was given but this is well documented.

During the Q&A section someone asked how to obtain a declared service in application code! The answer was surprisingly simple, that declared services are registered with the Eclipse ServiceRegistry so they can be retrieved the same way any Eclipse service is obtained, such as the ISelection or IHandler services. The details are a little fuzzy to me now but I believe this means, rather than using a BundleContext and/or ServiceTracker, a service should be requested by interface from one of several ServiceProviders available throughout Eclipse. I'm pretty sure the Site is the best entry point for this. I think we need to test this and replace our current efforts to get services with this more correct, less-dependency-involved method. Given the information provided in Singlesourcing for Eclipse 4.x and Eclipse 3.x though, we might want to consider creating special classes to do this workbench interaction that we can remove when we migrate to Eclipse 4.x. This solves the question left at the end of 10 signs you're doing OSGi wrong. We also should make sure we're always using the 1.1 schema.