Dokumente mit XML-Standards wie DocBook oder TEI zu erstellen ist an sich einfach. Eine Syntax, die es ermöglicht ein Schreibprojekt in vielerlei Gestalt zu produzieren. Trotzdem bin ich früher oft zurückgezuckt, wenn ich daran dachte, schnell mal eine Änderung an einem alten Projekt vorzunehmen, oder ein neues aufzusetzen.
Woher das Zucken kam, kann ich am Beispiel von DocBook leicht illustrieren. Zur Arbeit mit DocBook gibt es zwei Bibeln. Norman Walshs “DocBook 5: The Definitive Guide” beschreibt den Aufbau der DocBook-Dokumente, Bob Staytons “DocBook XSL: The Complete Guide” die Transformation in die jeweiligen Endprodukte. Schaut man sich nur einfach mal das Inhaltsverzeichnis von DocBook XSL an, so sieht man, dass sich der erste Teil des Werks fast nur mit Werkzeugen beschäftigt, dem Installieren und Konfigurieren der Werkzeuge, die aus dem XML-Urtext ein oder mehrere Endprodukte (HTML, PDF etc.) machen sollen. Nun ja, elektronisches Publizieren beruht nun mal auf Software, und jeder Software-Entwickler hatte ähnliche Probleme seine Entwicklungsumgebung aufzusetzen.
Die Schritte im Aufsetzen einer DocBook-Produktionsumgebung sind:
- Komponenten finden und herunterladen,
- Komponenten konfigurieren,
- die einzelnen Komponenten zu einem Prozess zusammenfassen.
Der letzte Punkt bestand meist aus einem Skript, das eben die verschiedenen Prozessoren nacheinander aufrief. Erst wenn man das hatte, war man auf der sicheren Seite, musste nicht bei jeder Textänderung die einzelnen Abläufe manuell starten.
Dieses Vorgehen ist meist nicht sonderlich schwierig, aber zeitaufwendig. Schwierig konnte es aber auch werden, meist dann wenn sich die einzelnen Komponenten irgendwie auseinander entwickelt hatten, inkompatibel geworden waren. Dann hieß es Alternativen suchen, ältere Versionen oder ganz andere Komponenten.
Besonders misslich konnte es werden, wenn man ein älteres, abgeschlossenes Projekt wieder anfasste, nur um eine klitzekleine Änderung zu machen. Da hat man die einstmals
verwendeten Komponenten meist nicht mehr zur Hand, sie wurden schon längst durch neuere Versionen ausgetauscht. Und die machten dann komische Dinge mit dem alten Projekt.
Wie gesagt, in der Software-Entwicklung hatte man dieselben Probleme. Man fand auch eine Lösung dafür, die sich auch gut übertragen lässt: Maven.
Mavens Aufgabe ist es, automatisiert Artefakte (man beachte die neutrale Begrifflichkeit) zu erstellen. Dafür bekommt es eine Projektdatei, eine Art Rezept, an die Hand. In dieser Projektdatei (POM genannt) sind die für die Produktion nötigen Schritte und die notwendigen Komponenten definiert. Insofern stellt eine POM keine große Änderung zu früheren Werkzeugen wie Ant oder Make dar.
Allerdings ist Maven etwas schlauer als seine Vorgänger. Maven weiss, sozusagen, dass
- Software-Komponenten Versionen haben,
- Software-Komponenten von anderen Komponenten und deren Versionen abhängen,
- wo diese Software-Komponenten zu finden sind,
- wie man sie installiert,
- und wie man sie aufruft.
Klingt ideal, oder? Muss man noch etwas tun?
Ja, leider. Maven ist natürlich keine künstliche Intelligenz. Mavens Leistung beruht auf den Software-Repositorien im Hintergrund. Dort sind die einzelnen SW-Komponenten abgelegt. Deren Beschreibung enthält jeweils (u.a.) die Version und etwaige Abhängigkeiten. Maven macht also im Prinzip nichts anderes als die Komponenten, die der Benutzer in seiner Projektdatei (POM) angegeben hat, im Repositorium zu suchen und herunter zu laden. Danach schaut es nach deren Abhängigkeiten und versucht diese zu laden. Diese Schritte werden wiederholt bis sämtliche Abhängigkeiten erfolgreich aufgelöst wurden. Ist die Software vorhanden geht Maven zur Ausführung über.
Dieser Prozess wird in der Projektdatei durch Plugins definiert. Ein Plugin stellt einen Funktionsblock dar, z.B. XML-Dokumente verarbeiten, mit einer oder mehreren Funktionen (goals), wie z.B. Dokument validieren oder Dokument transformieren. Neben der erwähnten Versionsinfo fürs Herunterladen bekommt so ein Plugin auch die Informationen für die Ausführung, also zum Beispiel welche Funktion, welche Eingabedokumente, wohin mit der Ausgabe. Somit wäre also auch die Konfiguration der Umgebung untergebracht. Wie läuft es mit der Ablaufsteuerung?
In einer POM können die Plugins in (fast) beliebiger Reihenfolge angegeben werden. Ihr Aufruf richtet sich primär nach der Phase im Maven-Lebenszyklus. Der Standard-Lebenszyklus orientiert sich an den Bedürfnissen von Software-Entwicklern. Da die Entwicklung von Medien-Produkten immer mehr mit Software zu tun hat, passt das meist ganz gut. Falls nicht kann man aber auch seinen eigenen Lebenszyklus definieren. Indem ein Benutzer Plugins auswählt und diese den einzelnen Phasen zuordnet wird das Skript erstellt. Durch die Angabe von Phase und Ziel (Funktion) wird dann die Ausführung der dafür konfigurierten Plugins gestartet.
Ist die POM einmal erstellt und produziert die gewünschten Ergebnisse hat man eine portable, ablauffähige Projektdefinition. Verschiebt man beispielsweise POM und Eingabedokumente auf einen anderen Rechner, lädt Maven dort die definierten Bausteine nach und beginnt sofort mit der Arbeit. Die Software-Installation und -Konfiguration geschieht dann automatisch (ok, Java und Maven müssen vorhanden sein), kein Aufwand mehr.
Auch wenn man ein altes Projekt wieder bearbeiten möchte hilft Maven weiter. Die Projektdatei enthält ja die Versionen der Komponenten, mit denen die Produktion einmal funktioniert hat. Ohne Änderungen an der POM wird Maven versuchen, die gleiche Umgebung wieder herzustellen, so dass die früher definierten Abläufe weiter laufen können. Begrenzt wird diese Wiederherstellungs-Fähigkeit primär durch die Verfügbarkeit der benötigten SW-Komponenten in den externen Repositorien. Aber das ist ein anderes Thema.