Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden

Installation und Konfiguration eines Maven Repository Mirrors

Maven Repository Mirror

Kurzeinführung

Das Dependency Management von Maven löst die in den pom.xml defi­nier­ten Abhängigkeiten auf und bezieht diese Artefakte über die in der Maven Konfigurationsdatei (pom.xml oder settings.xml) defi­nier­ten Repositories bzw. Mirrors. Ein Repository ist eine Anwendung, die via URL Mapping das ange­for­derte Artefakt sucht und letzt­lich aus­lie­fert, sofern es im Repository abge­legt wurde. Da ein Repository meist nur anwen­dungs­spe­zi­fi­sche Artefakte beinhal­tet, müs­sen bei Implementierung eines Projekts, wel­ches z.B. ver­schie­dene Frameworks ver­wen­det, meh­rere Repositories defi­niert wer­den. Ein Mirror ver­hält sich vom Ablauf her für den "Nutzer" (anfra­gen­des System) genauso. Via URL Mapping wird der Mirror ange­fragt, ob das Artefakt zur Verfügung steht, sollte dies der Fall sein, wird es aus­ge­lie­fert. Der Unterschied zum Repository ist, dass die Daten, die es sich bei den Artefakten, die sich in einem Mirror befin­den, nicht um die "Originale" han­delt, son­dern um Kopien. (des­halb Mirror = Spiegel)

Abarbeitung eines Mirrors

Der große Vorteil von Mirror Repositories ist, dass die Abhängigkeiten zu Fremdrepositories redu­ziert wird. Der fol­gende Ablauf macht dies deutlich:

Initialer Aufruf:

  1. loka­ler Rechner fragt Mirror an, ob sich das gefor­derte Artefakt auf die­sem Server befindet
  2. der Mirror Server fin­det nichts im eige­nen loka­len Repository und fragt die exter­nen Repositories an (Abhängigkeit zu einem oder meh­re­ren Fremdsystemen)
  3. das externe Repository lie­fert Artefakt an Mirror
  4. Mirror legt Artefakt in sein eige­nen loka­les Repository und sen­det es dann an loka­len Rechner

Weitere Aufrufe durch andere Rechner:

  1. loka­ler Rechner fragt Mirror an, ob sich das gefor­derte Artefakt auf die­sem Server befindet
  2. der Mirror Server fin­det das Artefakt und lie­fert es dem loka­len Rechner aus

Wie man durch diese Abläufe sehen kann, gibt es nur beim initia­len Aufruf eines Artefakts eine Abhängigkeit zu einem Fremdsystem. (Hinweis: In Mirror Repositories besteht die Möglichkeit auch eine Verfallszeit anzu­ge­ge­ben. Sollte diese über­schrit­ten wer­den, dann ver­hält sich der Ablauf wie beim initia­len Bezug des Artefakts.) Diese Reduktion der Abhängigkeit zahlt bereits bei mehr als einem Entwickler (ein loka­len Rechner) aus.

Sonatype Nexus

Die Java Anwendung Sonatype Nexus (Link: http://nexus.sonatype.org) ermög­licht eben einen sol­chen Mirror Server ein­zu­rich­ten. Die Konfiguration kann bequem über ein Webinterface durch­fge­führt wer­den. So kön­nen pro­blem­los neue Repositories hin­zu­ge­fügt wer­den. Zur Authentifizierung kann u.a. ein LDAP Server ange­bun­den werden.

Konfiguration für lokale Rechner

In der settings.xml müs­sen die fol­gen­den Zeilen ein­ge­tra­gen 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 pass­wort­ge­schützt sein, muss noch der fol­gende Schnippsel ein­ge­fügt werden:

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

Eine zusätz­li­che Anpassung ist not­wen­dig, wenn auch Snapshot Artefakten bezo­gen wer­den sol­len. Innerhalb des akti­ven Profils müs­sen die fol­gen­den 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 not­wen­dig, aller­dings kann an die­ser Stelle eine "Fake" URL ange­ge­ben. Durch die ID wird die Konfiguration des zuge­hö­ri­gen Mirror gezo­gen, wobei u.a. die URL durch die Mirror URL ersetzt wird.

Ergänzungen

In Nexus ist es mög­lich soge­nannte Routings anzu­ge­ben. Diese sind sehr prak­tisch, da u.a. ein URL Pattern defi­niert wer­den kann, dass für meh­rere Repositories "matched". Der Vorteil hier­bei ist, dass die lokale Maven Konfiguration nie ange­passt wer­den muss, wenn neue Repositories hin­zu­ge­fügt wer­den. Es ist ledig­lich erfor­der­lich, dass neue Repository über das Webinterface zum ent­spre­chen­den Routing Eintrag auf­zu­neh­men. Die Konfiguration der loka­len Rechner ver­wei­sen ledig­lich auf das Routing URL Pattern.

Die Bedienung des Webinterfaces ist sehr intui­tiv gehal­ten, sodass ich in die­sem Beiitrag dar­auf nicht ein­ge­gan­gen bin.

Fazit

Die Verwendung eines Mirror Servers ermög­licht es die Abhängikeiten zu exter­nen Repositories zu redu­zie­ren. Des Weiteren ist gro­ßer Vorteil, dass das Repository in den eige­nen Händen und Verantwortungsbereich liegt. Zudem kann sich die Performance für das Beziehen der Artefakten um eini­ges ver­bes­sern, da zum einen nur noch ein klei­ner Nutzerkreis dar­auf zugreift und zum ande­ren auch stär­kere Maschine für den Mirror instal­liert wer­den können.

Im spe­zi­el­len kann mit­tels Nexus die Konfiguration der Repositories für die loka­len Rechner mini­miert wer­den.  (Stichwort: Routing) Das mit­ge­lie­ferte Webinterface erlei­chert unge­mein die Konfiguration und ermög­licht vor­al­lem eine ver­bes­serte Ü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 exter­nes Repository (sei es auch nur zum tes­ten) ein­ge­bun­den wer­den kann.

Also eher die­ser Vorgang:
-> Artefakt im Nexus nicht vorhanden
-> Versuche Repository aus pro­jekt pom.xml -> SUCCESS

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

Was pas­siert dann aber mit den Repository die über den Nexus ein­ge­bu­den sind die nicht auf cen­tral 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 tat­säch­lich alles über das interne Repository gehen. Das hat natür­lich die beschrie­be­nen Vorteile, dass die Abhängigkeiten zen­tral gebün­delt und vor allem schnel­ler ver­füg­bar sind. Gleichzeitig ent­steht der von dir ange­führte Nachteil, dass expli­zit kon­fi­gu­rierte Repositories in "pom.xml" Dateien nicht ange­spro­chen wer­den kön­nen. Das ist ins­be­son­dere von Nachteil, wenn man selbst das Nexus nicht kon­fi­gu­rie­ren kann, um das Repository hinzuzufügen.

In dem Fall sollte man die lokale Konfiguration ggf. doch anders gestal­ten, z.B. indem man das lokale Nexus als wei­te­res Repository in sei­ner pom.xml hin­zu­fügt und ledig­lich "cen­tral" dar­über spiegelt.

Es gibt aber auch einen wei­te­ren Vorteil nur "ein" Repository zu ver­wen­den. Repositories in einer pom.xml zu defi­nie­ren, ist nicht gerade Best Practice, da nicht gewähr­leis­tet ist, dass das Repository immer ver­füg­bar ist. Fällt die­ses näm­lich mal aus, dann kann unter Umständen das gesamte Projekt nicht mehr gebaut wer­den und die Fehlersuche gestal­tet sich als schwie­rig. Wir hat­ten mal so einem Fall, in dem die URL zum Artefakt den­noch mit "200" geant­wor­tet hat und in der pom.xml dann eine Webseite aller "Diese Seite exis­tiert nicht mehr" gespei­chert war. Da ist stun­den­lan­ges Fehlersuchen garantiert.

Comments are closed.

Pin It on Pinterest