OSGi: Blueprint vs. Spring DM

Question

Je suis un peu confus à propos de Blueprint et Spring DM:

De ce que je pense est vrai:

• Spring DM est un framework défini par Spring Source
• Blueprint est un framework défini par l'OSGi Alliance
• Blueprint a "repris" beaucoup de ses idées de Spring DM

Non?

Pouvons-nous nous attendre à ce que ces deux cadres deviennent un dans l’avenir (fusion)? Si non, lequel sera le plus à l'épreuve du futur?

Answer 1

OSGi 4.2 introduit la spécification Blueprint Service basée sur le projet Spring Dynamic Modules pour lequel Spring DM (2.x) est l’implémentation de référence (RI).

En bref: Blueprint est une spécification, Spring DM est une implémentation de Blueprint API.

Answer 2

Blueprint a été développé par OSGi Alliance sous la direction de SpringSource / Interface21.

Toutefois, si vous cherchez un moyen de tirer parti de l'utilisation d'OSGi, les services de déclaration (DS) avec des annotations entre des ensembles (services). D'après mon expérience, vous n'avez pas vraiment besoin du câblage XML lorsque vous créez de petits ensembles cohérents. DS utilise beaucoup mieux les services que Blueprint / Spring DM, car ils ont tendance à vouloir "masquer" la dynamique, alors que DS en simplifie l'utilisation.

Answer 3

Ma compréhension est que SpringDM est un projet mort. Vérifiez les GA et les dates de sortie. Si bien qu'il a beaucoup contribué à l'élaboration de la spécification à la fin il a eu une mauvaise approche pour les chargeurs de classe. Apache-Bélier est un solide plan de mise en œuvre. Notez que l'utilisation de plan n'exclut pas l'utilisation de printemps. Je suggère de Karaf comme une plate-forme robuste qui peut utiliser Eclipse Equinox ou Apache Felix pour OSGI moteur. J'aime plan contre DS si vous êtes en cours d'élaboration au niveau de l'application où vos services peuvent être utilisés par d'autres équipes ou d'organisations au sein de votre entreprise, de vos clients. Je pense que plan est aussi un meilleur ajustement pour les entreprises traditionnelles de l'informatique. Mais DS ou Ipojo peut être plus approprié en fonction de votre cible particulière de l'environnement.

Answer 4

En plus de ce que Dmytro Pishchukhin a répondu, il convient de noter que le projet Spring DM est un projet un peu mort, car DM 2 n’est jamais parvenu à une version "release".

Au lieu de cela, il a été versé à la fondation Eclipse où il a été muté dans le projet Gemini Blueprint .

Answer 5

Dans l'introduction de l'Gemini Plan de la documentation, ils expliquent clairement la différence : http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html

Je reproduis ici :

Chapitre 1. Spring Dynamic Modules devient Eclipse Gemini Plan

À la fin de 2009, en tant que membre de la Gemini proposition de projet, SpringSource contribué Printemps Modules Dynamiques (aussi connu comme le Printemps OSGi) projet de la Fondation Eclipse. Spring DM v2 base de code a été déplacé à Eclipse.org avec son outil de suivi et de forum. Le projet a pris une double licence en vertu de la Licence Apache et EPL.

Alors que le nom a changé, le code et sa fonctionnalité reste la même. Existant Printemps DM les applications peuvent être facilement migrer vers Eclipse Gemini Plan comme mentionné dans le guide de migration.