IDEDev: Ein eigenes Maven Repository (Artifactory)

Post to Twitter

Moin!

Wenn man anfängt Maven für seine Anwendungsentwicklung zu verwenden, gibt es ein paar Hürden zu überstehen. Erstmal die formale Struktur des Projektmanagements zu verstehen oder auch das Dependency-Management.

Das sind logische und logistische Hürden, die man nach einiger Zeit gut beherrschen kann. Was mir aber dazu große Probleme bereitete, sind technische Schwierigkeiten auf die ich naturgemäß kein Einfluss nehmen kann: Der Zugriff auf externe Repositories.

Maven benötigt für alle Komponenten (Quellen, Build-Plugins und Ausgabe) eine Benennung und Versionierung. Das erfolgt über eine Koordinate: groupId/artifactId/version. Da diese universelle Koordinate keine Herkunft beschreibt, verwendet Maven ein Repository-Orientiertes System. Das ist vergleichbar mit dem Ubuntu (Debian) Packages Service, wo es mir erlaubt ist per apt-get Anwendungen zu installieren oder mit einem Update zu versehen.

So ein zentrales Repository erreiche ich über das Internet. Das central Repository von Maven wird damit folgendermaßen deklariert:

  <repositories>
    <repository>
      <id>central</id>
      <name>Maven Repository Switchboard</name>
      <layout>default</layout>
      <url>http://repo1.maven.org/maven2</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>

Da das Repository aber schon Standard definiert ist, muss man dies niemals in einem eigenen Pom hinterlegen (außer man wollte was daran ändern).

So ein zentrales Repository ist natürlich ungeheuer bequem. Nie wieder nach 3rd-Party Bibliotheken suchen. Maven stellt alles für mich und mein Build zusammen.

Aber man handelt sich auch damit technische Probleme ein:

  1. Verfügbarkeit
  2. Existenz
  3. Zuverlässigkeit
  4. Bandbreite

D.h.: Ist das Repository erreichbar, oder ist gerade entweder das Repository ausgefallen oder meine Internetverbindung? Existiert die benötigte Komponente als Artifakt-Bündel in dem zentralen Repository? Ist die Komponente in der angeforderten Version technisch einwandfrei? Wie schnell kann ich auf die Inhalte des Repostories zugreifen.

Viele Anfangsschwierigkeiten beruhten bei mir darauf, dass ich neben dem central-Repository auch z.B. auf das NetBeans-Repository zugreifen musste aber mal der eine und mal der andere nicht während des Builds reagierten. Wenn mein lokales Repository durch mvn noch nicht gefüllt wurde (als Mirror), schlägt der Build fehl. In einer produktiven Umgebung ein GAU.

Auch gibt es z.B manche JAR’s gar nicht als gelistetes Artifakt. Zwar kann ich JAR’s in das lokale Repository laden, habe dann aber das Problem , dass ich mir so wieder ein lokale Build-Umgebung aufbaue, die nicht universell auf jedem Rechner ausführbar ist.

Es ist mir sogar passiert, dass zwar das Artifakt existierte, aber der Inhalt (JAR oder pom.xml) korrupt gewesen sind. Warum auch immer.

Wenn die Bandbreite nicht stimmt, konnte sich ein Build mal ziemlich lange aufhängen, bevor man ein Ergebnis hatte.

Ich habe mich also sehr früh damit beschäftigt ein eigenes Repository in meinem Unternehmen aufzubauen. Es gibt ein paar freie und kommerzielle Lösungen. Da ich schon Hudson als Buildserver einsetze und ich auch die Oberfläche von Artifactory sehr angenehm fand, lag meine Wahl schon früh auf diese OpenSource-Variante.

Artifactory begegnet alle oben aufgelisteten Nachteile und bietet mir ein vollständiges Maven-Repository für meine Entwicklungen.

Artifactory dient mir als Mirror. D.h. in Artifactory werden mehrere Repositories verwaltet, die automatisch angefragt werden, wenn ich Artifactory nach einer Maven-Koordinate befrage. Setze ich also Artifactoryals Repository in mein pom.xml  geht die Anfrage zu ein Artifakt an Artifactory. Findet Artifactory die Komponente nicht in seinem eigenen Repository, lädt es diese aus der konfigurierten Repository-Liste. Für mein Build ist dieser Vorgang absolut transparent.

Somit erhalte ich immer die beste Bandbreite und muss mir keine Sorgen über die Verfügbarkeit eines Repositories machen.

Zwei weitere Probleme: Zuverlässigkeit und Existenz werden dadurch begegnet, dass ich bestimmte Bibliotheken explizit veröffentlichen kann. Ist mir bekannt, dass ein Artifakt korrupt ist oder existiert das überhaupt nicht, suche ich mir die passende Komponente, lade sie in das Artifactory hoch und versehe diese mit einer Koordinate.

Durch eine direkte Integration in meinem Hudson Buildserver ist es mir außerdem möglich meine erzeugten Artifakte von einem Build-Prozess wieder in das Artifactory einzuspielen und damit zu veröffentlichen (das ginge mit Maven allein natürlich auch, aber die UI-Verknüpfung ist sehr hilfreich).

Artifactory läuft in meinem Unternehmen auf einem Glassfish Server. Es läuft aber in jedem Servlet-Container als WAR Autodeploy. Es gibt inzwischen auch Standalone-Service-Installationen.

Beste Grüße!

Dieser Beitrag wurde unter Maven abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.