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
• Blueprint is a framework defined by the OSGi Alliance
• Blueprint has "taken" many of it's ideas from Spring DM

No?

Can we expect that those two frameworks become one in the future (merge)? If not, which one will be the most future-proof?

Shedevil

Answer 1

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

Bani

And nowadays, Spring DM's successor Gemini Blueprint is the reference implementation (source) of the Blueprint API. – Townswoman

Answer 2

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.

Spradling

@ArchimedesTrajano Declarative Services – Geraldgeralda

Thanks, I just checked the link, and I think I'd still tend towards Blueprint. – Remarque

Your choice, just don't say I warned you :-) – Spradling

Answer 3

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.

Ovipositor

Could you share any insight / pointer about Spring DM's "bad approach to classloaders" ? I'm curious about the consequences. – Cayes

Answer 4

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.

Cayes

In addition to that =) there's Apache Aries which is another implementation of the Blueprint spec. – Elderberry

Answer 5

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.

Uttasta