OSGi: Blueprint vs. Spring DM

spring-dm

Question

Estoy un poco confundido sobre Blueprint y Spring DM:

Por lo que creo que es verdad:

• Spring DM es un marco definido por Spring Source
• Blueprint es un marco definido por OSGi Alliance
• Blueprint ha "tomado" muchas de sus ideas de Spring DM

¿No?

¿Podemos esperar que esos dos marcos se vuelvan uno en el futuro (fusión)? Si no, ¿cuál será la más a prueba de futuro?

Answer 1

OSGi 4.2 presenta la especificación del servicio Blueprint basada en el proyecto Spring Dynamic Modules para el cual Spring DM (2.x) es la Implementación de referencia (RI).

En resumen: Blueprint es una especificación, Spring DM es una implementación de Blueprint API

Answer 2

Además de lo que respondió Dmytro Pishchukhin, debe tenerse en cuenta que el proyecto Spring DM es algo así como un proyecto muerto, ya que DM 2 nunca llegó a una versión de "lanzamiento".

En cambio, se contribuyó a la fundación Eclipse, donde se transformó en el proyecto Gemini Blueprint .

Answer 3

Blueprint fue desarrollado en OSGi Alliance bajo la dirección de SpringSource / Interface21.

Sin embargo, si está buscando una forma de aprovechar OSGi use los Servicios Declarativos (DS) con anotaciones entre paquetes (servicios). En mi experiencia, realmente no necesitas el XML de cableado cuando haces pequeños paquetes cohesivos. DS es mucho mejor trabajando con servicios que Blueprint / Spring DM ya que tienden a querer "ocultar" la dinámica mientras que DS simplemente hace que su uso sea trivial.

Answer 4

En la introducción de la documentación de Gemini Blueprint, explican claramente la diferencia: http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html

Reproduzco aquí:

Capítulo 1. Spring Dynamic Modules se convierte en Eclipse Gemini Blueprint

A finales de 2009, como miembro de la propuesta de proyecto de Gemini, SpringSource contribuyó con Spring Dynamic Modules (también conocido como proyecto Spring OSGi) a la Fundación Eclipse. La base del código Spring DM v2 se ha movido a Eclipse.org junto con su rastreador de problemas y el foro. El proyecto se convirtió en doble licencia bajo Apache License y EPL.

Si bien el nombre ha cambiado, el código y su funcionalidad siguen siendo los mismos. Las aplicaciones existentes de Spring DM se pueden migrar fácilmente a Eclipse Gemini Blueprint como se menciona en la guía de migración.

Answer 5

Tengo entendido que SpringDM es un proyecto muerto . Verifique la GA y fechas de lanzamiento. Entonces, aunque contribuyó mucho al desarrollo de la especificación, al final tuvo un mal enfoque para los cargadores de clases. Apache-Aries es una implementación fuerte de blueprint. Tenga en cuenta que el uso de blueprint no impide el uso de la primavera. Sugeriría Karaf como una plataforma robusta que puede usar Eclipse Equinox o Apache Felix para el motor OSGI. Me gusta blueprint versus DS si está desarrollando a nivel de aplicación donde sus servicios pueden ser utilizados por otros equipos u organizaciones dentro de su empresa, o extendidos por sus clientes. Creo que blueprint también se adapta mejor a los entornos informáticos empresariales tradicionales. Pero DS o Ipojo pueden ser más apropiados dependiendo de su entorno objetivo particular.