Ein OSGi first Software Artifact Repository

Package Drone: Repositories ohne Schmerzen

Jens Reimann, Jürgen Rose

© Shutterstock / Julia Tim

Package Drone ist ein neues Software Artifact Repository für (nicht nur) Java-Build-Ergebnisse. Durch die konzeptionelle Berücksichtigung der Besonderheiten von OSGi Bundles wird die Erstellung und Bereitstellung der Bundles in verschiedenen Repository-Formaten enorm vereinfacht. Die grundsätzliche Ausrichtung darauf, beliebige Artefakttypen und Repository-Varianten zu unterstützen, erlaubt es auch, neue Formate mit wenig Aufwand zu integrieren.

Jedes Team, das ernsthaft Software entwickelt, steht ab einem gewissen Punkt im Entwicklungsprozess vor zwei Fragen: Wo kommen die verwendeten Bibliotheken her? Und wo werden die erzeugten Build-Ergebnisse abgelegt? Die Antwort wird in vielen Fällen lauten: Ein Software Artifact Repository. Zu dem Zeitpunkt, zu dem man eine interne Bibliothek entwickelt, die wiederum von anderen aus dem Team verwendet wird, muss man sich Gedanken über dauerhafte Aufbewahrung und Versionierung machen.
Solange man sich in der Maven-Welt bewegt kann man sich dann, je nach Belieben, aussuchen, ob man nun Nexus, Artifactory oder Archiva verwendet. Sobald man aber diesen Pfad nur ein wenig verlässt und Wünsche wie P2- oder R5-Support hat, wird die Luft schon etwas dünner. OSGi Bundles bieten mit Bundle- und Package-Referenzen sowie mittlerweile mit Capabilities und Requirements viel mächtigere und komplexere Möglichkeiten, Abhängigkeiten zu definieren, als es Dependencies, die auf Maven-Koordinaten (Group ID, Artifact ID und Version – GAV) basieren, erlauben. Dazu kommt noch der Spezialfall im Eclipse-Ökosystem, wo Bundles über Features und Categories in P2-Repositories zusammengefasst werden. Diese hohe Komplexität bedingte, dass es sehr lange Zeit dauerte, bis mit Maven-Tycho überhaupt endlich ein Tool zur Verfügung stand, das zumindest im Erstellungsprozess diese Welten vereinigen konnte.
Selbst dann bleiben einige Probleme ungelöst. Zum einen ist es nicht möglich, nahtlos P2 Repositories und Maven-Dependencies miteinander zu kombinieren, selbst wenn die Abhängigkeiten als OSGi Bundles zur Verfügung stünden. Zum anderen bieten bestehende Repository-Lösungen nur wenig zufriedenstellenden Support für beispielsweise P2. Wenn man dazu betrachtet, dass in einem P2 Repository zudem alle Informationen enthalten sind, um den Inhalt auch im neuen OSGi-R5-XML-Index zur Verfügung zu stellen (um es vielleicht mit den BND-Tools zu verwenden), dann stellte sich schnell Frustration ein, weil es bisher keine Tools mit solch einer Funktionalität gab.
Im Folgenden soll gezeigt werden, welche Vorteile Package Drone gegenüber anderen Software Artifact Repositories bietet, und einige Use Cases erklärt werden.

Installation

Package Drone kann einfach über RPM oder Debian-Pakete installiert werden. Neben einem aktuellen Linux und Java 8 wird noch eine PostgreSQL- oder MySQL-Instanz benötigt. Diese muss sich nicht auf dem gleichen Computer befinden.

Noch etwas einfacher geht es mit Docker oder OpenShift. Bei Docker muss man nur das Docker Image ctron/package-drone von Docker Hub mit docker pull ctron/package-drone herunterladen.

Für OpenShift gibt es einen so genannten QuickStart. Hat man bereits einen OpenShift-Account, folgt man dem Deploy-Link. Damit wird automatisch eine neue Package-Drone-Instanz inklusive Datenbank erstellt und konfiguriert.

Nach der Installation erfolgt das weitere Set-up im Browser. Solange noch nicht alle notwendigen Set-up-Aufgaben vollständig abgeschlossen wurden, wird generell auf die Set-up-Seite umgeleitet. Die wesentlichen Schritte bestehen darin, die Datenbankverbindung festzulegen und optional einen Mailserver zu konfigurieren. Bei OpenShift sind diese Aufgaben automatisch erledigt.

Wichtigster Schritt ist als Letztes das Anlegen eines Users, der dann die Managerrolle erhalten muss. Das Berechtigungskonzept von Package Drone ist aktuell sehr einfach. Es wird unterschieden zwischen einem anonymen Benutzer sowie einem Manager und Administrator. Anonyme Benutzer dürfen grundsätzlich nur lesend auf die Daten zugreifen, Konfigurationsoptionen bleiben ihnen verborgen. Administratoren dürfen das System konfigurieren, jedoch nicht Artefakte oder die Konfiguration von Kanälen verändern, dies bleibt den Managern vorbehalten. Es ist also nicht so, dass der Administrator automatisch alles „darf“, was im ersten Moment etwas verwirrend erscheinen mag. Es spricht natürlich nichts dagegen, einen Benutzer gleichzeitig als Manager und Administrator zu definieren. Alle Schritte zur Installation und Konfiguration werden im Detail im Wiki erklärt.

Grundlegende Konzepte und Verwendung

Package Drone ist als flexibler Repository-Manager angelegt und bietet im Wesentlichen zwei ganz allgemeine Ebenen zur Ablage an: Kanäle (channels) und Artefakte (artifacts). Kanäle sind Container für Artefakte, die in ihrer Funktionalität mithilfe von Aspekten (channel aspects) erweitert werden können. Über verschiedene Schnittstellen (z.B. maven deploy) oder über die Weboberfläche können Artefakte in einen Kanal geladen werden. Damit sind diese erst einmal grundsätzlich abgelegt und können, je nach vorhandenen Adaptern, auch wieder abgerufen werden.

Daneben können zu einem Artefakt auch Kinder zugeordnet sein, die vielleicht in einem Build-Prozess entstehen und fest zu dem Hauptelement gehören (z. B. Quellcode-JARS). Wird das Elternelement gelöscht, verschwinden auch die Kinder (Abb. 1).

Abb. 1: Zusammenhang zwischen Kanälen, Artefakten, Aspekten und Adaptern

Abb. 1: Zusammenhang zwischen Kanälen, Artefakten, Aspekten und Adaptern

Die eigentlichen Funktionalitäten in einem Kanal werden durch die Aspekte bereitgestellt. Aktuell beinhaltet das Funktionen wie: Extraktion von Metadaten, Erstellung abgeleiteter Artefakte, Zusammenfassung von Kanälen und Reaktion auf Änderungen im Kanal.

Ein Beispiel ist der „OSGi“-Aspekt. Er extrahiert die OSGi-relevanten Metadaten aus MANIFEST.MF. Der „P2 Metadata“-Aspekt wiederum erzeugt virtuelle Artefakte, die die OSGi-Metadaten als P2-Fragmente widerspiegeln (Abb. 2). Der P2-Repository-Aspekt fasst einen Kanal zusammen und aggregiert alle P2-Metadaten zu einem P2 Repository.

Abb. 2: Erzeugung virtueller Artefakte

Abb. 2: Erzeugung virtueller Artefakte

Adapter (adaptors) stellen Schnittstellen zu anderen Repository-Systemen dar. Der P2-Adapter stellt über ein HTTP-Servlet ein P2 Repository für jeden Kanal zur Verfügung, der Maven-Adapter wiederum ein Maven Repository. Bei Letzterem ist es nicht nur möglich, die Repository als Maven Repository zu lesen, sondern auch neue Artefakte via mvn deploy hochzuladen.

Eine besondere Form der Artefakte sind Generatoren (generators). Sie werden nicht hochgeladen, sondern explizit erstellt. Abhängig von ihrem Inhalt und ihrer Konfiguration erstellt der Generator bei jeder Änderung der Konfiguration oder des Kanals neue „generierte Artefakte“ als Kinder des Generatorartefakts. Beispielsweise gibt es einen P2-Feature-Generator, der ein P2-Feature erzeugt, das sämtliche OSGi Bundles aus einem Kanal referenziert.

Use Case: Repository Authoring

Einer der Ausgangspunkte für die Entwicklung von Package Drone war der Wunsch, ein P2 Repository manuell ohne großen Aufwand erstellen zu können. Beispielsweise kann es notwendig sein, externe Abhängigkeiten in einen P2-basierten Build-Prozess zu integrieren. Auch wenn mit Eclipse Orbit ein P2 Repository mit vielen OSGi-fähigen Bibliotheken zur Verfügung steht, gibt es genug Bibliotheken oder Versionen, die nicht über P2 erreichbar sind. Hier kann beispielsweise ein eigener Kanal erstellt werden, der als Container für externe Abhängigkeiten eines Projekts verwendet wird. Artefakte können manuell hochgeladen werden oder mit dem Maven Importer direkt aus einem Maven Repository (oder Maven Central) importiert werden. Dabei ist es nicht wichtig, wie die OSGi Bundles erstellt werden, denn Package Drone kann die OSGi-Metadaten selbständig extrahieren. Wurde das OSGi Bundle also z. B. mit dem Maven Bundle Plugin erstellt, kann es trotzdem von Package Drone von Maven Central importiert und die OSGi-Metadaten können extrahiert werden.

Ein immer wiederkehrendes Problem an dieser Stelle ist der Import der Java Sources. Eclipse PDE verwendet das Konzept der Source Bundles. Hierbei handelt es sich um OSGi-ähnliche Bundles, die den Sourcecode zu einem OSGi Bundle beinhalten. Maven hingegen hat für ein JAR-File jeweils ein eigenes Source Attachment. Package Drone kann beim Import von einem Maven Repository direkt das Source Attachment mit herunterladen und es in ein Eclipse Source Bundle konvertieren. Wird das Source Attachment als Kindelement eines Artefakts hinzugefügt, funktioniert dies auch beim manuellen Hochladen. Verantwortlich hierfür ist der „Eclipse Source Bundle“-Aspekt.

Es ist möglich, sich noch ein Eclipse-Feature und eine P2-Kategorie erzeugen zu lassen. Anschließend können die externen Abhängigkeiten direkt mit P2, Eclipse PDE und Maven Tycho verwendet werden.

Use Case: Integration Builds

Möchte man einen klassischen Integration/Nightly Build zugänglich machen, so gibt es mit Package Drone aktuell sogar vier verschiedene Ansätze. Zum einen kann man das resultierende P2 Repository im ZIP-Format einfach via mvn deploy in einen Kanal laden und über den Unzip Adapter wieder auslesen. Der Unzip Adapter erlaubt ein Entpacken on the fly eines Artefakts mit einem stabilen URL. Somit ist es möglich, mit einem fixen URL ein gepacktes P2 Repository in einem Kanal direkt anzusprechen (Abb. 3).

Abb. 3: Deployment neuerer Versionen und Darstellung als P2 oder R5 Repository

Abb. 3: Deployment neuerer Versionen und Darstellung als P2 oder R5 Repository

Optional kann man über den P2-Unzip-Aspekt die hochgeladene ZIP-Datei entpacken lassen. Hier werden alle Bundles und Features ausgepackt. Der OSGi-Aspekt extrahiert die notwendigen Metadaten, der P2-Metadata- und der P2-Repository-Aspekt erstellen gemeinsam ein neues P2 Repository für diesen Kanal. Hierbei ist es dann möglich, automatisch P2-Kategorien erstellen zu lassen, und zwar über den ganzen Kanal hinweg. Dies hat den Vorteil, dass alle Artefakte im Kanal zusammen betrachtet werden. Bei der Installation über P2 wird dann beispielsweise die Kategorie anzeigt, unterhalb der Kategorie werden alle Features, optional auch in allen Versionen, angeboten.

Die dritte und vierte Variante liegen nah zusammen. Anstelle des fertigen P2 Repository werden die Artefakte einzeln mithilfe von mvn deploy hochgeladen. Maven Tycho erzeugt während dem Build bereits P2-Metadatenfragmente und lädt diese auch in ein Maven Repository hoch. Package Drone kann sie verwenden, um das P2 Repository zu erzeugen (Abb. 4).

Abb. 4: Separates Deployment von Bundle und P2 Metadaten

Abb. 4: Separates Deployment von Bundle und P2 Metadaten

Alternativ kann man mit dem „Tycho Cleaner“-Aspekt ein Hochladen dieser Artefakte unterbinden und mit dem OSGi- und dem P2-Metadata-Aspekt sie als virtuelle Artefakte neu erstellen lassen (Abb. 5).

Abb. 5: Deployment eines Bundles mit automatischer Erstellung der P2-Metadaten

Abb. 5: Deployment eines Bundles mit automatischer Erstellung der P2-Metadaten

Der P2-Repository-Aspekt, der das P2 Repository erstellt, sucht im Kanal nach bestimmten Artefakten für die Aggregation der Metadaten. Ob diese nun von Maven Tycho hochgeladen wurden oder von Package Drone erstellt werden, spielt hier keine Rolle.

Use Case: OSGi-R5-Repository-Support

Mit der OSGi-R5-Spezifikation wurde nun auch das bisher nicht standardisierte OBR (OSGi Bundle Repository) als Repository Service Specification formalisiert. Zum einen wird ein API spezifiziert, das verwendet werden kann, um sich benötigte Abhängigkeiten zu besorgen, zum anderen ist hier ein XML-Austauschformat definiert, das den Inhalt eines Repositories beschreibt. Bisher gab es allerdings kein Repository, das dieses unterstützt. Mit Package Drone ist es hier möglich, gleichzeitig alle Artefakte auch im R5-Format zu indizieren, ohne den Deployment-Workflow umstellen zu müssen. Damit lassen sich sofort in Felix, Knopflerfish oder jedem anderen Container, der den Service unterstützt, Bundles aus dem Repository laden.

Weitere Möglichkeiten: APT, NPM

Package Drone wurde von Grund auf modular konzipiert (Kasten „Plug-in-basierte Webentwicklung – Die Systemarchitektur von Package Drone“). Zwar war OSGi als primärer Verwendungszweck angedacht, jedoch gab es von Anfang an die Idee, auch andere Repository-Formate abzubilden.

Mit Debian bzw. APT und NPM gibt es zwei zusätzliche Output-Adapter die in Package Drone verfügbar sind. Ähnlich wie bei OSGi, kann Package Drone die Metadaten aus einem Debian Package (.deb) extrahieren und sie in Form eines APT Repository zur Verfügung stellen. Dabei ist es wieder nicht wichtig, wo die Artefakte herkommen, ob via mvn deploy, manuell hochgeladen oder über HTTP importiert. Die für APT relevanten Zusatzinformationen werden über die Weboberfläche eingepflegt. Ebenso ist es möglich ein GPG-Keyfile anzugeben, das verwendet wird, um das Repository automatisch zu signieren.

Der NPM Adapter funktioniert nach dem gleichen Prinzip. Als reiner Output-Adapter ist es zwar möglich, Pakete aus dem Repository zu installieren, aber noch kann man derzeit keine NPM-Pakete nach Package Drone pushen.

Plug-in-basierte Webentwicklung – Die Systemarchitektur von Package Drone

Die Entwicklung von Package Drone sollte auch eine Fingerübung sein, um sich mit den neuen Möglichkeiten von Java 8 vertraut zu machen. Dies ist der Grund, warum das aktuelle Java-Release eine zwingende Voraussetzung ist. Zudem wollten wir ein wenig erforschen, welchen Stand die OSGi-Plug-in-basierte Webentwicklung zurzeit hat.

Wie erwartet bringt Java 8 an vielen Stellen angenehme Verbesserungen mit sich und verleiht der Entwicklung neuen Schwung. Hierbei gab es keine unangenehmen Überraschungen.

Etwas anders sieht es aus, wenn man versucht zu analysieren, welche Möglichkeiten zur Webentwicklung mit OSGi bestehen. Abgesehen von Eclipse RAP, das vielleicht die offensichtliche gewesen wäre (aber für unseren Geschmack und Zweck zu wenig „webmäßig“), haben wir keine umfassende Lösung gefunden, die sich out of the box verwenden ließe. Eclipse Virgo ist vielleicht von der Grundidee das passendste, aber die Art und Weise, wie sich z. B. die Datenbank konfigurieren lässt (nicht basierend auf der OSGi DataSourceFactory!), und die vielen Spring-spezifischen Eigenheiten sprachen für uns gegen einen Einsatz. Eine weitere Möglichkeit hätte wohl auch der Webkern von Nuxeo als Basis für eine eigene Entwicklung sein können. Hier war aber nicht klar, wie man ihn alleinstehend einsetzen kann, auch aus Mangel an Dokumentation. Zwei große Anforderungen sollten erfüllt sein: Zum einen sollte das Einrichten so intuitiv gemacht werden, wie man es von diversen Webanwendungen her kennt, inklusive dem Konfigurieren der Datenbankverbindung; zum anderen sollten neu hinzugekommene Plug-ins in der Lage sein, ihre Controller und Pfade zur Laufzeit zu konfigurieren. Diese Anforderungen, zusammen mit der Tatsache, dass die existierenden Frameworks dies nicht bieten, führte dazu, existierende Bibliotheken mit etwas eigenem Glue-Code zu einem recht simplen Framework zu vereinen.

Aufgrund unserer Erfahrung mit Equinox und EclipseLink entschieden wir uns, diese Bibliotheken als Basis zu verwenden. Damit war mehr oder weniger auch klar, Jetty als Basis für den Webserver zu verwenden. Tatsächlich bedingen diese technischen Entscheidungen, dass an der ein oder anderen Stelle EclipseLink- oder Jetty-spezifische Implementierungsdetails enthalten sind. Wichtig für uns war an dieser Stelle, dass dies keine Auswirkungen auf einen Entwickler hat, der Plug-ins für Package Drone erstellen möchte.

Die Konfiguration der Datenbank dem Benutzer zu überlassen, erwies sich durch die Verwendung der OSGi DataSourceFactory im Zusamenhang mit dem ConfigurationAdmin als lösbare Aufgabe. Seit Ende 2014 beinhaltet auch der PostgreSQL-Treiber eine DataSourceFactory; er kann somit hier endlich unverändert verwendet werden. Es stellte sich jedoch heraus, dass sowohl bei MySQL/MariaDB als auch bei PostgreSQL der Support für Blobs, speziell das Streaming, aus verschiedenen Gründen nicht zu gebrauchen ist. Dies führte zu der Möglichkeit, die Daten auch im Dateisystem zu speichern.

Gern hätten wir Spring MVC als Basis für die Controller verwendet, aber die Tatsache, dass an so vielen Stellen davon ausgegangen wird, dass das Wiring nur initial einmalig erfolgt, machte dem einen Strich durch die Rechnung. Somit mussten wir uns selbst ein kleines, von Spring MVC stark inspiriertes Framework erstellen.

Ein Fazit: Es gab zwar eine Reihe von kleineren und größeren Problemen zu lösen, um die ganzen Komponenten im OSGi-Kontext sauber zu integrieren, aber nach diesem einmaligen Aufwand ist die Entwicklung sehr angenehm. Es überrascht manchmal sogar ein wenig, wie schön die verschiedenen Features miteinander interagieren und dafür sorgen, wie die unterschiedlichen Services ihre Dienste je nach Anforderung bereitstellen und auch wieder verschwinden lassen.

Ausblick

Rund um das Thema OSGi bietet Package Drone schon jetzt eine ganze Reihe von Funktionen, die die Arbeit erleichtern. Als noch recht junges Projekt bleibt natürlich trotzdem Raum für viele Verbesserungen und Erweiterungen. Vor allem die Implementierung zusätzlicher Datei- und Repository-Typen (z.B. RPM/YUM) sind Teil der Roadmap. Sicherlich gibt es auch noch viele weitere Einsatzmöglichkeiten, an die bisher noch keiner gedacht hat und für die noch Stolpersteine aus dem Weg geräumt werden müssen. Bug-Reports und Erweiterungswünsche werden im Bugtracker verwaltet und harren interessierter Kontributoren. Es gibt sogar eine Dokumentation, die natürlich auch von weiteren Autoren profitieren würde.

Aktuell wird die Entwicklung hauptsächlich bei GitHub geführt. Dies soll auch in Zukunft so bleiben, allerdings soll Package Drone ein Projekt der Eclipse Foundation werden. Das notwendige Project Proposal wurde bereits abgegeben. Auch hierfür werden weitere Kontributoren und Interessenten gesucht. Der Wechsel zur Eclipse Foundation soll nicht nur die Zusammenarbeit mit anderen Projekten wie Tycho, P2 oder PDE verbessern, sondern Package Drone selbst auch auf eine verlässliche Basis stellen. Um diesen Schritt so einfach wie möglich zu gestalten, ist Package Drone bereits jetzt schon unter der EPL lizenziert und verwendet nur Bibliotheken, die später mit der Eclipse-Umgebung vereinbar sind.

Fazit

Es wurde gezeigt, dass Package Drone eine interessante Alternative zu gängigen Software Artefact Repositories bietet, vor allem wenn Funktionalitäten rund um OSGi und P2 benötigt werden. Das flexible Konzept und die einfache Erweiterbarkeit erlauben einen einfachen Einstieg in die Weiterentwicklung oder die Implementierung weiterer existierender oder eigener Repository-Formate, wie die Implementierung für Debian und APT bereits zeigt. Darüber hinaus bietet das bei der Entwicklung entstandene Grundgerüst eine gute Ausgangsbasis, um eigene modularisierte Webprojekte zu realisieren.

Aufmacherbild: Remote air drone with a box via Shutterstock / Urheberrecht: Julia Tim

Geschrieben von
Jens Reimann
Jens Reimann ist Entwicklungsleiter bei der IBH SYSTEMS GmbH in München. Er ist Gründer und Chefentwickler des Eclipse-SCADA-Projekts (bisher bekannt als openSCADA, http://openscada.org). Seine Spezialität ist das Reverse Engineering und die Implementierung von Protokollen. Er ist Koautor eines Buchs zum Thema MES (Manufacturing Execution System).
Jürgen Rose
Jürgen Rose ist Senior Developer bei der IBH SYSTEMS GmbH in München. Er ist Mitentwickler des Eclipse-SCADA-Projekts. Obwohl eigentlich ein Python-Liebhaber, findet er Java inzwischen gar nicht mehr so übel.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: