Wie schon beim Überblick zur Verwendung von Maven für die Generierung von Publikationen gesagt, benötigt Maven Repositorien, Speicher für Software-Bausteine, um definierte Arbeitsumgebungen automatisch bereitstellen zu können. Wie sieht das nun genau aus?
Nach der Installation von Maven nutzt die Anwendung das voreingestellte Repositorium Maven Central oder einen der Spiegelserver. Damit hat man schon mal einen Großteil der für Maven bereitgestellten Software im Zugriff. Mit der wachsenden Popularität dieses Werkzeugs stellen aber auch andere Entwickler oder Organisationen Repositorien bereit, die man zusätzlich einbinden kann.
Standardmäßig verwendet Maven ein persönliches Repositorium (1), in dem versteckten Verzeichnis ~/.m2 im Benutzerordner. Dort werden die einmal geladenen Versionen aus den öffentlichen Repositorien zwischengespeichert, und auch die selbst erstellten Artefakte. In diesem Verzeichnis können auch alle Einstellungen zu anderen Repositorien und zum eigenen Umgang mit Maven gemacht werden.
Die Vorteile dieser Vorgehensweise liegen auf der Hand. Sie ist unaufwendig und man hat sein eigenes kleines Baustein-Archiv immer dabei. Die Nachteile werden aber auch schnell klar. Einmal hat das versteckte Verzeichnis die Angewohnheit schnell zu wachsen, speziell wenn man öfters mit neuen Bausteinen oder anderen Versionen experimentiert. Das Management per Hand ist etwas schwierig. Wechselt man außerdem einmal den Rechner ist alles weg, inklusive der Einstellungen und der selbst-erstelleten Produkte. Aber in einem Ein-Personen-Betrieb mit gelegentlicher Nutzung kann man diese Nachteile noch mit Sicherungskopien umgehen.
Eine andere Vorgehensweise wäre die Nutzung eines Managers für binäre Repositorien (2). Produkte wie Apache Archiva oder Sonatype Nexus (Nexus Professional bzw. Nexus Open Source) können bei der Nutzung von binären Repositorien in verschiedener Hinsicht helfen:
- als Proxy und Cache für externe Repositorien, einmal heruntergeladene Bausteine stehen für alle internen Nutzer zur Verfügung,
- als Repositorium für interne Software,
- oder als Veröffentlichungspunkt für eigene Software, die an Dritte weiter gegeben werden soll
Gerade mit der Proxy/Cache-Funktion (1) stellt ein solcher Manager sicher, dass auch ältere Software-Versionen über längere Zeit im Zugriff bleiben. Wenn externe, öffentliche Repositorien vielleicht einmal aus Platzgründen ältere Versionen auslagern müssen, kann man so solche Alt-Versionen vorhalten, wenn eigene Projekte noch davon betroffen sind. (Über die in den POMs definierten Abhängigkeiten lässt sich übrigens sehr schön feststellen, welche Module von welchen externen Bausteinen/Versionen abhängig sind, man muss nicht mutmaßen!)
Da digitale Publikationen immer interaktiver werden, d.h. der funktionale Software-Anteil steigt gegenüber den klassischen Inhalts-Ressourcen (Text, Bild) an, ist ein solches internes Binär-Repositorium wahrscheinlich sowieso eine gute Ergänzung zum schon vorhandenen CMS für Inhalte.