Estoy un poco confundido acerca de Blueprint y primavera DM:OSGi: Modelo vs primavera DM
Por lo que creo es cierto:
¿No?
¿Podemos esperar que esos dos marcos se conviertan en uno en el futuro (fusión)? Si no, ¿cuál será la más a prueba de futuro?
OSGi 4.2 introduce la especificación de servicio Blueprint basado en proyecto Módulos de elasticidad dinámica para los que (2.x) Spring DM es la implementación Referencia (RI).
En resumen: Blueprint es una especificación, Primavera DM es una implementación de la API Blueprint
Además de lo que respondió, hay que señalar que el proyecto de Primavera DM es un poco un proyecto muerto, como Dmytro Pishchukhin DM 2 nunca llegó a una versión de "lanzamiento".
En su lugar fue contributed to the Eclipse foundation donde se transformó en Gemini Blueprint project.
Además de eso =) hay Apache Aries, que es otra implementación de la especificación Blueprint. – earcam
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 las 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.
¿Para qué sirve DS? –
@ArchimedesTrajano [Servicios declarativos] (http://wiki.osgi.org/wiki/Declarative_Services) – pauli
Gracias, acabo de consultar el enlace, y creo que todavía tendré tendencia hacia Blueprint. –
Según tengo entendido SpringDM is a dead project. 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.
¿Podrías compartir alguna idea/puntero sobre el "mal enfoque de los DM ClassModer" de Spring DM? Tengo curiosidad sobre las consecuencias. – user1310749
En la introducción de la documentación Blueprint Gemini 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 aportó el proyecto Spring Dynamic Modules (también conocido como 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.
Mientras que 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.
Y hoy en día, el sucesor Gemini Blueprint de primavera DM es la implementación de referencia ([fuente] (http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/blueprint. html)) de Blueprint API. –