Sollte ich zuerst POM oder MANIFEST zuerst verwenden, wenn ich eine OSGi-Anwendung mit Maven entwickle?

Question

Es gibt zwei Hauptansätze bei der Entwicklung einer OSGi-Anwendung mit Maven: zuerst POM-first und MANIFEST.

Ich bin auf der Suche nach einer Antwort in Form einer Tabelle, die Vor-und Nachteile jeder Methode zeigt.

Um genauer zu sein, ich möchte auch wissen, wie sie sich auf:

• Maturity von Toolset
• Herstellerunabhängigkeit
• Entwicklung Leichtigkeit (die Leute zu finden, umfasst, die die Entwicklung tun können auf die Tooling)
• Kompatibilität
• Vermeidung ClassNotFound
• Vermeidung manueller Arbeit

Answer 1

Derzeit ist es das, was ich mit

POM-First Pros kommen kann

• Nutzen bestehende Maven Fähigkeiten, Repositories und Werkzeuge (Maven-Bundle-Plugin).
• wahrscheinlich einfacher, Leute zu finden, die wissen, wie pom.xml zu verwalten, anstatt MANIFEST.MF zusammen mit pom.xml
• Die meisten Informationen in MANIFEST.MF kann sich von der pom.xml erhalten werden.
• Kann mit anderen IDEs arbeiten, nicht nur mit Eclipse-basierten.
• Weniger invasive, fügen Sie einfach den einzigen Plugin und das Verpackungstyp verändern zu "bündeln"

POM-First Cons

• ClassNotFoundException eher zur Laufzeit auftreten. Dies kann jedoch mit der Pax-Prüfung gemildert werden (obwohl die Einrichtung sehr kompliziert ist).
• Noch müssen Sie verstehen, wie das MANIFEST eingerichtet wird, um sicherzustellen, dass das instructions Konfigurationselement korrekt eingestellt ist.

manifest erste Pros (mit tycho-Maven-Plugin)

• scheinen die empfohlene Vorgehensweise, oder zumindest etwa als der empfohlene Ansatz gesprochen werden, aber ich kann nicht wirklich sehen, Warum hat es einen signifikanten Nutzen? (Daher warum diese Frage gestellt wurde).
• Geeignet für die Entwicklung von Eclipse-Plugins und integriert sich gut mit PDE
• Bietet Werkzeuge zum Testen und ermöglicht somit ClassNotFoundException während JUnit Tests anstelle von Laufzeit angezeigt werden.

manifest erste Cons

• scheint nur auf Eclipse-basierte IDEs gut zu funktionieren. Sie müssen Eclipse nicht verwenden, aber ohne die PDE möchten Sie?
• Verstößt gegen DRY-Prinzipien, da ich tun muss, halten Sie die Namen und Versionen von POM und MANIFEST.MF synchron.
• Benötigen Sie Dinge in einer bestimmten Art und Weise
• Sie können nicht nennen mischen kann bestehende Maven Multiprojekt Installationen bedeuten nicht nur
auf OSGi Unterstützung tack
• Viel mehr Konfiguration im Vergleich zu maven-Bundle-Plugin benötigt wird, um weniger zu erhalten Warnungen: http://wiki.eclipse.org/Tycho/Reference_Card#Examplary_parent_POM
• Müssen Testfälle ein separates Projekt machen. Es wird nicht ausgeführt, wenn es in src/test/java eingebaut ist.
• Scheint, dass es nur Klassen testen wird, die ausgesetzt sind, mit anderen Worten die in ".internal." ist nicht testbar.

Wenn ich für eine Empfehlung für ein Unternehmen wurden gebeten, die Maven verwendet bereits und wollen OSGi bewegen, dann wäre es POM erste

Wenn ich für jemanden für eine Empfehlung gebeten wurden, wer macht Eclipse-Plugin-Entwicklung, dann ist es Manifest zuerst - mit Tycho

Answer 2

MANIFEST zuerst sperren Sie nicht zu Eclipse (obwohl ich überrascht wäre, wenn mehr als eine kleine Minderheit etwas anderes verwenden würde). Das MANIFEST ist die Datei, die zählt, und muss zu einem Jar hinzugefügt werden, unabhängig davon, wie Sie das tun.

Auf der anderen Seite sperrt POM zuerst vollständig zu Maven, Sie verlieren den Vorteil, dass ein OSGi-Bundle ein normales Glas ist, das Sie beliebig gestalten können.

Ich habe beide versucht, ich bevorzuge MANIFEST zuerst. Die MANIFEST-Datei ist eine wirklich wichtige Datei, ich ziehe es vor, diese Datei zu erstellen, anstatt eine Datei zu erstellen, die diese Datei erzeugt. Wenn etwas Seltsames passiert (und es wird irgendwann passieren), ist die MANIFEST-Datei die erste, die es überprüft, es ist einfacher, wenn es sich um eine eigene Datei handelt. Außerdem wirst du es sowieso kennen müssen.

Also, wenn Maven Ihr Alpha und Omega ist, wird Ihnen POM am besten zusagen, aber Sie werden die MANIFEST-Datei genau kennen müssen.

Answer 3

Ich denke, Sie sollten nach Anwendungsfall wählen. Für serverseitige OSGi-Projekte bevorzuge ich den ersten Pom-Stil. Es passt gut zu den Maven Builds und ist viel weniger fehleranfällig als Manifest zuerst. In der Tat bnd, was hinter dem Maven-Bundle-Plugin ist, bekommt das Manifest in den meisten Fällen ohne zusätzliche Konfig. Der Trick besteht darin, einige Benennungsregeln zu verwenden. Zum Beispiel, wenn Sie internes Paket impl oder internal nennen, wird das nicht exportiert. Mit diesem Stil können Sie nicht die Eclipse-Plugin-Perspektive verwenden (zumindest ohne bndtools, die ich nicht mag), aber ich habe diese Perspektive noch nicht vermisst. Ich bin ein Entwickler in den Apache Karaf, CXF und Camel Projekten, wo wir diesen Stil verwenden und es funktioniert super. Besonders für CXF und Camel ist es großartig, dass wir OSGi- und Nicht-OSGi-Implementierungen mit demselben Build und denselben Tools unterstützen können.

Für Eclipse RCP-Anwendungen Zuerst muss man sich mit Manifest befassen, da Sie die Plugin-Perspektive und die Eclipse-IDE-Tools benötigen. Wenn Sie das mit Maven kombinieren wollen, dann ist Tycho wahrscheinlich der Weg zu gehen.