Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

Installation und Konfiguration eines Maven Repository Mirrors

Maven Repository Mirror

Kurzeinführung

Das Dependency Management von Maven löst die in den pom.xml definierten Abhängigkeiten auf und bezieht diese Artefakte über die in der Maven Konfigurationsdatei (pom.xml oder settings.xml) definierten Repositories bzw. Mirrors. Ein Repository ist eine Anwendung, die via URL Mapping das angeforderte Artefakt sucht und letztlich ausliefert, sofern es im Repository abgelegt wurde. Da ein Repository meist nur anwendungsspezifische Artefakte beinhaltet, müssen bei Implementierung eines Projekts, welches z.B. verschiedene Frameworks verwendet, mehrere Repositories definiert werden. Ein Mirror verhält sich vom Ablauf her für den „Nutzer“ (anfragendes System) genauso. Via URL Mapping wird der Mirror angefragt, ob das Artefakt zur Verfügung steht, sollte dies der Fall sein, wird es ausgeliefert. Der Unterschied zum Repository ist, dass die Daten, die es sich bei den Artefakten, die sich in einem Mirror befinden, nicht um die „Originale“ handelt, sondern um Kopien. (deshalb Mirror = Spiegel)

Abarbeitung eines Mirrors

Der große Vorteil von Mirror Repositories ist, dass die Abhängigkeiten zu Fremdrepositories reduziert wird. Der folgende Ablauf macht dies deutlich:

Initialer Aufruf:

  1. lokaler Rechner fragt Mirror an, ob sich das geforderte Artefakt auf diesem Server befindet
  2. der Mirror Server findet nichts im eigenen lokalen Repository und fragt die externen Repositories an (Abhängigkeit zu einem oder mehreren Fremdsystemen)
  3. das externe Repository liefert Artefakt an Mirror
  4. Mirror legt Artefakt in sein eigenen lokales Repository und sendet es dann an lokalen Rechner

Weitere Aufrufe durch andere Rechner:

  1. lokaler Rechner fragt Mirror an, ob sich das geforderte Artefakt auf diesem Server befindet
  2. der Mirror Server findet das Artefakt und liefert es dem lokalen Rechner aus

Wie man durch diese Abläufe sehen kann, gibt es nur beim initialen Aufruf eines Artefakts eine Abhängigkeit zu einem Fremdsystem. (Hinweis: In Mirror Repositories besteht die Möglichkeit auch eine Verfallszeit anzugegeben. Sollte diese überschritten werden, dann verhält sich der Ablauf wie beim initialen Bezug des Artefakts.) Diese Reduktion der Abhängigkeit zahlt bereits bei mehr als einem Entwickler (ein lokalen Rechner) aus.

Sonatype Nexus

Die Java Anwendung Sonatype Nexus (Link: http://nexus.sonatype.org) ermöglicht eben einen solchen Mirror Server einzurichten. Die Konfiguration kann bequem über ein Webinterface durchfgeführt werden. So können problemlos neue Repositories hinzugefügt werden. Zur Authentifizierung kann u.a. ein LDAP Server angebunden werden.

Konfiguration für lokale Rechner

In der settings.xml müssen die folgenden Zeilen eingetragen werden:

<mirrors>
<mirror>
<id>my-mirror-repository</id>
<mirrorOf>*</mirrorOf>
<name>My Mirror Repository</name>
<url>http://[mirror_url]/nexus/content/repositories/[reponame|routing_path]</url>
</mirror>
</mirrors>

Sollte der Mirror passwortgeschützt sein, muss noch der folgende Schnippsel eingefügt werden:

<servers>
<server>
<id>my-mirror-repository</id>
<username>[username]</username>
<password>[password]</password>
</server>
</servers>

Eine zusätzliche Anpassung ist notwendig, wenn auch Snapshot Artefakten bezogen werden sollen. Innerhalb des aktiven Profils müssen die folgenden Zeilen ergänzt werden:

<pluginRepositories>
<pluginRepository>
<id>my-mirror-repository</id>
<!-- this url will be overriden by mirror settings -->
<url>http://nothing</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
<repositories>
<repository>
<id>my-mirror-repository</id>
<!-- this url will be overriden by mirror settings -->
<url>http://nothing</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>

Die Angabe der URL ist notwendig, allerdings kann an dieser Stelle eine „Fake“ URL angegeben. Durch die ID wird die Konfiguration des zugehörigen Mirror gezogen, wobei u.a. die URL durch die Mirror URL ersetzt wird.

Ergänzungen

In Nexus ist es möglich sogenannte Routings anzugeben. Diese sind sehr praktisch, da u.a. ein URL Pattern definiert werden kann, dass für mehrere Repositories „matched“. Der Vorteil hierbei ist, dass die lokale Maven Konfiguration nie angepasst werden muss, wenn neue Repositories hinzugefügt werden. Es ist lediglich erforderlich, dass neue Repository über das Webinterface zum entsprechenden Routing Eintrag aufzunehmen. Die Konfiguration der lokalen Rechner verweisen lediglich auf das Routing URL Pattern.

Die Bedienung des Webinterfaces ist sehr intuitiv gehalten, sodass ich in diesem Beiitrag darauf nicht eingegangen bin.

Fazit

Die Verwendung eines Mirror Servers ermöglicht es die Abhängikeiten zu externen Repositories zu reduzieren. Des Weiteren ist großer Vorteil, dass das Repository in den eigenen Händen und Verantwortungsbereich liegt. Zudem kann sich die Performance für das Beziehen der Artefakten um einiges verbessern, da zum einen nur noch ein kleiner Nutzerkreis darauf zugreift und zum anderen auch stärkere Maschine für den Mirror installiert werden können.

Im speziellen kann mittels Nexus die Konfiguration der Repositories für die lokalen Rechner minimiert werden.  (Stichwort: Routing) Das mitgelieferte Webinterface erleichert ungemein die Konfiguration und ermöglicht vorallem eine verbesserte Übersicht.

27. Juni 2011

Danke für den Artikel.

Aber wenn in der settings.xml steht * führt das dazu das in den Projekt poms kein externes Repository (sei es auch nur zum testen) eingebunden werden kann.

Also eher dieser Vorgang:
-> Artefakt im Nexus nicht vorhanden
-> Versuche Repository aus projekt pom.xml -> SUCCESS

Die Lösung ist central somit wird nur das central Repository über den nexus angefragt,

Was passiert dann aber mit den Repository die über den Nexus eingebuden sind die nicht auf central hören?

Siehe auch: http://maven.apache.org/guides/mini/guide-mirror-settings.html

http://maven.apache.org/guides/mini/guide-mirror-settings.html

Hallo Phillip,

Danke für den Hinweis, in dem Fall von Andreas würde ja tatsächlich alles über das interne Repository gehen. Das hat natürlich die beschriebenen Vorteile, dass die Abhängigkeiten zentral gebündelt und vor allem schneller verfügbar sind. Gleichzeitig entsteht der von dir angeführte Nachteil, dass explizit konfigurierte Repositories in „pom.xml“ Dateien nicht angesprochen werden können. Das ist insbesondere von Nachteil, wenn man selbst das Nexus nicht konfigurieren kann, um das Repository hinzuzufügen.

In dem Fall sollte man die lokale Konfiguration ggf. doch anders gestalten, z.B. indem man das lokale Nexus als weiteres Repository in seiner pom.xml hinzufügt und lediglich „central“ darüber spiegelt.

Es gibt aber auch einen weiteren Vorteil nur „ein“ Repository zu verwenden. Repositories in einer pom.xml zu definieren, ist nicht gerade Best Practice, da nicht gewährleistet ist, dass das Repository immer verfügbar ist. Fällt dieses nämlich mal aus, dann kann unter Umständen das gesamte Projekt nicht mehr gebaut werden und die Fehlersuche gestaltet sich als schwierig. Wir hatten mal so einem Fall, in dem die URL zum Artefakt dennoch mit „200“ geantwortet hat und in der pom.xml dann eine Webseite aller „Diese Seite existiert nicht mehr“ gespeichert war. Da ist stundenlanges Fehlersuchen garantiert.

Kommentar hinterlassen


Pin It on Pinterest