ich ein wenig verwirrt über Blueprint und Spring DM am:OSGi: Blueprint vs. Frühling DM
Von dem, was ich denke,gilt:
Nein?
Können wir erwarten, dass diese beiden Frameworks in Zukunft eins werden (Zusammenführung)? Wenn nicht, welches wird am zukunftssichersten sein?
OSGi 4.2 stellt die Blueprint-Service-Spezifikation basiert auf Frühling Dynamische Module Projekt, für das Frühjahr DM (2.x) ist die Referenzimplementierung (RI).
Kurz: Blueprint eine Spezifikation ist, ist Frühling DM eine Implementierung von Blueprint API
Zusätzlich zu dem, was Dmytro Pishchukhin beantwortet, sei darauf hingewiesen, dass der Frühling DM-Projekt ist etwas ein totes Projekt, wie DM 2 hat nie eine "Release" Version erreicht.
Stattdessen war es contributed to the Eclipse foundation, wo es in die Gemini Blueprint project mutierte.
Zusätzlich zu diesem =) gibt es Apache Widder, die eine andere Implementierung der Blueprint-Spezifikation ist. – earcam
Blueprint wurde in der OSGi Alliance unter Federführung von SpringSource/Interface21 entwickelt.
Wenn Sie jedoch nach einer Möglichkeit zur Nutzung von OSGi suchen, verwenden Sie Deklarative Services (DS) mit den Anmerkungen zwischen Bundles (Services). Meiner Erfahrung nach brauchen Sie die XML-Verkabelung nicht wirklich, wenn Sie kleine zusammenhängende Bündel erstellen. DS ist viel besser in der Arbeit mit Diensten als Blueprint/Spring DM, da sie dazu neigen, die Dynamik zu "verstecken", während DS es einfach macht, es zu benutzen.
Für was ist DS kurz? –
@ArchimedesTrajano [Deklarative Dienste] (http://wiki.osgi.org/wiki/Declarative_Services) – pauli
Danke, ich habe gerade den Link überprüft, und ich denke, ich würde immer noch in Richtung Blueprint neigen. –
Mein Verständnis ist, dass SpringDM is a dead project. Überprüfen Sie die GA und Release-Daten. Obwohl es am Ende viel zur Entwicklung der Spezifikation beitrug, hatte es einen schlechten Zugang zu Classloadern. Apache-Aries ist eine starke Blueprint-Implementierung. Beachten Sie, dass die Verwendung von Blaupausen die Verwendung von Federn nicht ausschließt. Ich würde vorschlagen, als eine robuste Plattform, die entweder Eclipse Equinox oder Apache Felix für die OSGI-Engine verwenden können. Ich mag Blueprint im Vergleich zu DS, wenn Sie auf der Anwendungsebene entwickeln, wo Ihre Dienste von anderen Teams oder Organisationen in Ihrem Unternehmen genutzt oder von Ihren Kunden erweitert werden können. Ich denke, dass Blueprint auch besser für herkömmliche Enterprise-Computing-Umgebungen geeignet ist. Aber DS oder Ipojo sind möglicherweise besser geeignet, abhängig von Ihrer speziellen Zielumgebung.
Könnten Sie einen Einblick/einen Hinweis auf Spring DMs "schlechte Herangehensweise an Klassenlader" geben? Ich bin neugierig auf die Konsequenzen. – user1310749
In der Einführung der Dokumentation Zwillinge Blueprint erklären sie deutlich den Unterschied: http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html
ich hier wiedergeben:
Kapitel 1.Spring Dynamic Modules wird zu Eclipse Gemini Blueprint
Ende 2009 hat SpringSource als Mitglied des Gemini Projektantrags Spring Dynamic Modules (auch Spring OSGi genannt) an die Eclipse Foundation gesponsert. Spring DM v2 code base wurde zusammen mit seinem issue tracker und forum auf Eclipse.org verschoben. Das Projekt wurde unter Apache License und EPL dual lizenziert.
Während der Name geändert wurde, blieben der Code und seine Funktionalität gleich. Vorhandene Spring DM-Anwendungen können wie im Migrationsleitfaden erwähnt leicht in Eclipse Gemini Blueprint migriert werden.
Und heutzutage, Frühling DM Nachfolger Zwillinge Blueprint ist die Referenzimplementierung ([Quelle] (http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/blueprint. html)) der Blueprint API. –