OSGi DevCon 2013
OSGi applications are assembled from loosely coupled bundles communicating via services. While this model provides huge flexibility and the ability to reuse components, it creates a challenge for the assembler of the application since it is unclear which bundles are needed, which are optional and which are unnecessary.
For example some dependencies are implicit, such as the provider of a service or an extender. We do not want to prematurely lock down these dependencies at build time, but at deployment time a specific provider must be found otherwise the application will fail to behave as expected. Furthermore when third-party libraries are used they often contain static dependencies on additional libraries, which in turn contain additional dependencies, and so on. Much time is wasted in finding a set of bundles that will actually resolve and run in the OSGi environment, and once such a set is found, developers tend to fear making changes to it.
The generic requirements and capabilities model introduced in OSGi Release 4.3, along with the standard Repository and Resolver specifications introduced in OSGi Release 5, provide answers for both of these problems. Using capabilities, we can describe dependencies in an abstract way without prematurely binding to specific providers. Using the resolver, we can narrow our focus to the very small set of bundles that describe our application at the top level, and allow all other dependencies to be computed and managed for us.
This talk begins with a brief technical overview of the new 4.3 and 5.0 specifications and how they can be used to assemble applications with ease. We then demonstrate both development tooling and a runtime platform that can be used to put these ideas into practice.