OSGi: Blueprint vs. Spring DM

Question

I am a little bit confused about Blueprint and Spring DM:

From what I think is true:

• Spring DM is a framework defined by Spring Source
• B

Answer 1

In the introduction of the Gemini Blueprint documentation they explain clearly the difference : http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html

I reproduce here :

Chapter 1. Spring Dynamic Modules becomes Eclipse Gemini Blueprint

In late 2009, as a member of the Gemini project proposal, SpringSource contributed Spring Dynamic Modules (also known as Spring OSGi) project to the Eclipse Foundation. Spring DM v2 code base has been moved to Eclipse.org along with its issue tracker and forum. The project became dual licensed under Apache License and EPL.

While the name has changed, the code and its functionality remained the same. Existing Spring DM applications can be easily migrated to Eclipse Gemini Blueprint as mentioned in the migration guide.

Answer 2

In addition to what Dmytro Pishchukhin answered, it should be noted that the Spring DM project is somewhat a dead project, as DM 2 never reached a "release" version.

Instead it was contributed to the Eclipse foundation where it mutated into the Gemini Blueprint project.

Answer 3

OSGi 4.2 introduces the Blueprint Service specification based on Spring Dynamic Modules project for which Spring DM (2.x) is the Reference Implementation (RI).

In short: Blueprint is a specification, Spring DM is an implementation of Blueprint API

Answer 4

Blueprint was developed in the OSGi Alliance under the lead of SpringSource/Interface21.

However, if you're looking for a way to leverage OSGi use Declarative Services (DS) with annotations between bundles (services). In my experience, you do not really need the wiring XML when you make small cohesive bundles. DS is much better in working with services than Blueprint/Spring DM since they tend to to want to "hide" the dynamicity while DS just makes it trivial to use.

Answer 5

My understanding is that SpringDM is a dead project. Check the GA and release dates. So although it contributed much to the development of the specification in the end it had a bad approach to classloaders. Apache-Aries is a strong blueprint implementation. Note that use of blueprint does not preclude use of spring. I would suggest Karaf as a robust platform that can use either Eclipse Equinox or Apache Felix for the OSGI engine. I like blueprint versus DS if you are developing at the application level where your services may be used by other teams or organizations within your enterprise, or extended by your customers. I think blueprint is also a better fit for traditional enterprise computing environments. But DS or Ipojo may be more appropriate depending on your particular target environment.