OSGi: Does Blueprint replace Declarative Services?

Question

The new R4.2 spec for OSGi describes the Blueprint service, for dependency injection and service wiring.

Does Blueprint replace Declarative Services (which is still part

Answer 1

For my experience within Felix based environment, DS is the only dependency injector that is mature enougth and that provides consistency with others parts of OSGi Compendium specs such as ConfigAdmin.

Blueprint seems to me as a political inclusion of Spring DM in OSGi specs.

iPojo is an alternative based on Java annotations instead of XML descriptors, its hide some part of OSGi foundation.

Answer 2

Another issue is that blueprint services -as far as I know- are all present in one container, the blueprint container- while declarative services are made available in the bundles that reference them. Especially with Equinox this results in different behavior. DS should be used over blueprint when you want to adhere to the strict class-loading approach that equinox advocates.

Answer 3

If you've used Spring before, Blueprint services are more familiar to use. Declarative services are not as powerful but widely adopted in OSGi containers.

Answer 4

I asked myself the same question and while discussing this with others involved in the topic, the tenor was that although the two are overlapping to some degree, the use case when to use which is pretty different. DS is a light weight solution to avoid Activators and model service dependencies declaratively. BP is basically a DI container targeting enterprise deployments. It is also more common for "regular" Java developers not that familiar with the dynamic nature of OSGi (hiding a lot behind proxies).

Implementation wise, there are two projects working on it (all of them are container agnostic and not officially released). Spring DM 2.0 is going to provide an implementation (2.0.0.M1 already contains a working implementation) as well as Apache as part of its geronimo project (slideshow).