Für diesen Artikel setze ich jetzt einfach mal voraus, dass die Begriffe und Technologien hinter Java, Maven, Repository, Eclipse und Tomcat bekannt und geläufig sind. Und nein, jeweiliger Profi muss man zum Verständnis nicht sein.

Was wollen wir?

An ein firmeneigenes Repository – oder auch: corporate repository – gelten besondere Anforderungen. Diese können bei einem “einfach privat-eigenen” verändert werden, aber man kommt meistens auf folgende Punkte:

  1. Ein Repository soll den Entwicklern zum Deployen der eigenen Artifakte und Module zur Verfügung gestellt werden. Wahlweise übernimmt dies auch ein automatischer Build-Agent wie Hudson, TeamCity und haste-nicht-gesehen.
  2. Ein Repositorymanager soll als p_roxy_ fungieren. In einer Firma spart dies nicht nur einfache Bandbreite. Da ein solcher Manager in der Regel im lokalen Netz steht, sind die Interaktionszeiten um ein Vielfaches besser.
  3. Ein so genanntes third party pepository für die Abhängigkeiten, die unbedingt notwendig sind und wovon es keine Maven-Abhängigkeiten gibt.

Für Punkt zwei spricht auch eine wesentlich einfachere Konfiguration der Clients (Entwicklerprofile), da nur noch ein Repository eingetragen werden muss. Alle “bekannten” Repositories werden zentral gebündelt, damit schwindet natürlich gleichzeitig die “Freiheit” des einzelnen Entwicklers, andere “unbekannte” Repositories zu verwenden. Dies ist jedoch vernachlässigbar, weil: Diese “Freiheit” schränkt im Endeffekt den Buildprozess und auch die Wiederverwendbarkeit ein. Das Hinzufügen von weiteren Repositories in die POM ist aus Gründen der Versionisierung und Nachhaltigkeit auch keine optimale Lösung. Dennoch, alles nur eine Sache der Konfigurations der Clients.

Was brauchen wir?

Es gibt eine Reihe von Repository-Managern, die allesamt viel können. Die Wahl auf Nexus fällt hier aus folgenden Gründen:

  • der Footprint ist mit 30 Megabyte wesentlich kleiner als bspw. Artifactory
  • die interne Verzeichnisstruktur entspricht mehr oder weniger 1:1 der realen Organisationsstruktur eines Maven-Repositorys (im Vergleich: Artifactory speichert ein eigenes Datenbankstruktur ähnliches Layout)
  • Nexus und das Eclipse-Plugin m2eclipse sind vom gleichen Hersteller Sonatype und ergänzen sich; nach dem Umstellen bemerkt der Entwickler keinen Unterschied in der Suche, Auto-Discovery, o.ä.

Eine umfangreiche Online-Dokumentation ist auf der Nexus-Seite zu finden.

Installation

Nexus wird unter anderem als WAR ausgeliefert, insofern die Installation in einen Tomcat ein leichtes ist. Beachtenswert ist dabei nur, dass Nexus ein Verzeichnis ~/sonatype-work erstellt. Da sich dort unter Umständen viele Nutzdaten ansammeln, kann ein Verschieben (symbolischer Link?) nicht verkehrt sein. Da sich mit der Laufe der Zeit einiges an Daten ansammeln kann, sollte der Platz nicht zu sparsam vermessen sein.

Umfang

Nachdem Tomcat bzw. Nexus gestartet ist, kann man sich mit dem Default-Daten admin/admin123 anmelden (analog mit den Daten der anderen beiden Benutzern!).

Nexus kommt bereits mit einer Reihen von vorkonfigurierten, eigenen hosted repositories einher.

  • releases sammelt alle Release-Artifakte der Firma
  • snapshots sammelt alle Snapshot-Artifakte der Firma
  • third-party sammelt alle Release-Artifakte externer Quellen, wofür es keine Maven-Repositories gibt (oder wo man jenes Repository nicht generell zur Verfügung stellen will), gutes Beispiel ist ein (aktueller) Oracle-JDBC-Treiber

Daneben gibt es so genannte proxy repositories, die praktisch gesehen nur aus einem Index bestehen. Wie ein Proxy hängen sie sich zwischen dem Client und dem tatsächlichen Repository und cachen alle Artifakte lokal. Selbst der Index ist mehrere Megabytes groß, das sollte man nicht vernachlässigen. Voreingetragene proxy repositories sind Apache Snapshots, Codehaus Snapshots, Central Maven Repository (Maven1/Maven2-Repository-Konverter sind in Nexus vorhanden a.k.a. virtual repositories).

Die grouped repositories sind auch rein virtuelle Gruppierungen von verschiedenen Repositories. Das Standard Repository “Public” ist in der einfachsten Konfiguration eine Sammlung aller (aktivierten) Repositories auf dem Manager – also sowohl der externen Spiegel, der Third-Parties als auch den eigenen Artifakten.

Konfiguration

Die Aktivierung und Verwaltung von (neuen) Repositories ist abhängig der eigenen Bedürfnisse. Meistens sinnvoll ist es jedoch, bei den drei großen Spiegeln (proxy repositories) in dem Konfigurationstab das Indizieren (Download Remote Indexes) zu aktivieren. Je nach Belieben kann man in der Gruppe Administration auch das Aktualisierungsverhalten steuern.

Konfiguration: Deployment

Um ein Deployment zu gewährleisten, muss man nebst Kenntnis der Repository-URL (eben die URL) nur wissen, ob der anonyme Zugriff erlaubt sein soll, oder ob man einen Deployment-Benutzer einrichten und nutzen willst. Falls eine Richtlinie vorschreiben sollte, dass dies nur ein Build-Agent machen darf, ist ein (geheimes) Passwort oder Schlüssel unabdingbar.

Konfiguration: Client

Nehmen wir an, der Nexus-Manager ist auf dem Host 192.168.0.10:8080/nexus installiert. In der einfachen Installation und Konfiguration sammeln sich im public repository praktisch alle relevanten Artifakte (sowohl Releases als auch Snapshots).

<settings>
  <mirrors>
    <mirror>
      <id>corporate</id>
      <name>Corporate Repository</name>
      <url>http://192.168.0.10:8080/nexus/content/groups/public</url>
      <mirrorOf>*</mirrorOf>
    </mirror>
  </mirrors>
</settings>

Der Deployment-User benötigt ggf. Zugangsdaten für das entsprechende Repository.

Ein Client wie m2eclipse sollte danach einen kompletten Rebuild des Index machen.