Ich habe eine Eclipse 4-Anwendung erstellt, und ich benötigte eine jar , die eine Funktionalität als Teil meiner Anwendung anbietet (dies könnte alles Mögliche sein, zB log4j , um es trivial zu machen).
Ich habe die jar als Teil des Klassenpfads meines Projekts ( Right Click->Configure Build Path ) hinzugefügt, aber zur Laufzeit ist mein Dienst mit einem ClassNotFound Fehler gescheitert (von OSGI ich denke?).
Wie auch immer, es hat sich herausgestellt, dass es zumindest so ist, wie ich es verstanden habe, dass ich das jar als Teil eines anderen Plugin hinzufügen und eine Abhängigkeit von meiner Anwendung / meinem Dienst für dieses neue Plugin erstellen soll.
I.e. Ich habe ein Plugin Project from Existing JAR archives erstellt.
Diesmal funktionierte das Setup.
Also, wenn ich das verstehe, sollten wir bei der Entwicklung für Eclipse / OSGi jars nicht direkt in den Klassenpfaden hinzufügen, sondern sie über Plugins hinzufügen (warum?).
Frage: Wenn ich das richtig finde Was ist die Standardpraxis, um jars bei der Entwicklung eines Projekts einzubeziehen?
Definiere / Erstelle ein Plugin Project from existing JAR archives und füge all die benötigten Third-Party-Libraries dort hinzu, oder hast ein anderes Plugin-Projekt pro benötigtem jar oder etwas anderes vielleicht?
Entschuldigung, wenn meine Terminologie nicht korrekt ist. Ich bin neu in OSGi und Eclipse Programmierung
Hinweis: Wenn Sie über jars sprechen, verweise ich nicht auf andere OSGi-Dienste. Ich beziehe mich auf die Norm, fertige, zuverlässige Bibliotheken von Drittanbietern zu verwenden, die von vielen Teilen einer Anwendung benötigt werden. Z.B. log4j oder eine XML-Parsing-Bibliothek oder apache commons etc
Für die Laufzeit bestimmen immer das Manifest und die Header dort, was sich in Ihrem Paketklassenpfad befindet. Es gibt drei Möglichkeiten, um auf ein Jar zuzugreifen:
Import-Paket-Header. Dies ist der empfohlene Weg. Sie definieren einen Import pro Paket, das Sie benötigen. Ihr jar, auf das Sie zugreifen möchten, muss in der Laufzeitumgebung als Paket bereitgestellt werden. Es muss auch alle benötigten Pakete exportieren.
Require-Paket. Dies ist eine andere Möglichkeit, auf Bündel zuzugreifen. Sie definieren die ID des benötigten Pakets und sehen alle Pakete, die es exportiert. Da Require-Bundle Sie enger an das andere Bündel bindet, sollte der Import-Package-Weg bevorzugt werden.
Bündel-Klassenpfad. Dies ermöglicht das Hinzufügen von Gläsern zu Ihrem Klassenpfad, die Sie in Ihr eigenes Paket einbetten. Dies sollte nur ein letzter Ausweg sein, wenn der andere Weg nicht funktioniert. Sie können unangenehme Classloading-Probleme haben, wenn Sie dies mit anderen Methoden kombinieren.
Sie finden viele vordefinierte Bundles in maven central. Viele Gläser enthalten bereits heute ein OSGi-Manifest. Für die Fälle, in denen dies nicht der Fall ist, werden viele Gläser von servicemix als Bündel neu verpackt. Siehe groupId: org.apache.servicemix.bundles. Es gibt auch das Federpaket-Repository, wo Sie weitere finden.
Nachfolgend habe ich einige Ressourcen aufgelistet, die Sie vielleicht lesen könnten:
Die Beispiele, die Sie erwähnt haben, sind als OSGi-Bundles verfügbar, sodass Sie sie nicht selbst erstellen müssen. Normalerweise verwenden Sie keine direkten JAR-Abhängigkeiten in OSGi. Normalerweise verwenden Sie Paket- oder Paketabhängigkeiten. Im Beispiel von log4j, auf das Sie sich beziehen, sollten Sie Paket importieren verwenden, da es mehrere Paketanbieter geben kann (neuere log4j jar, Quellcode-Version von älteren log4j, slf4j-Implementierung ...). Dadurch werden die Codeabhängigkeiten vom aktuellen Provider getrennt.
Diese Abhängigkeiten werden über Ihr Manifest verwaltet, nicht über Ihren Projektklassenpfad. In einem Eclipse-Plug-in-Projekt wird der Klassenpfad zum Erstellen des Projekts von den Einträgen im Manifest abgeleitet.
Obwohl Sie keine Dienste verwenden, werden alle Codeabhängigkeiten weiterhin über das Manifest verwaltet.
Exakt das gleiche Problem, dem wir in unserem Projekt gegenüberstanden. Wir haben ein Legacy-Jar, das nicht OSGi-kompatibel ist. Wir erstellen einen lib-Ordner parallel zu BundleContent und fügten ihn dem Klassenpfad-Abschnitt von manifest hinzu.
%Vor%Es ist nicht notwendig, Pakete unnötigerweise zu exportieren und zu importieren, wenn nur ein Bündel es verbrauchen wird,
Tags und Links eclipse java plugins eclipse-plugin osgi