Installieren Sie das lokale Glas mit Maven

1. Das Problem und die Optionen

Maven ist ein sehr vielseitiges Tool und seine verfügbaren öffentlichen Repositories sind unübertroffen. Es wird jedoch immer ein Artefakt geben, das entweder nirgendwo gehostet wird , oder das Repository, in dem es gehostet wird, ist riskant, da es möglicherweise nicht verfügbar ist, wenn Sie es benötigen.

In diesem Fall gibt es einige Möglichkeiten:

  • Beißen Sie auf die Kugel und installieren Sie eine vollwertige Repository-Verwaltungslösung wie Nexus
  • Versuchen Sie, das Artefakt in eines der seriöseren öffentlichen Repositories hochzuladen
  • Installieren Sie das Artefakt lokal mit einem Maven-Plugin

Nexus ist natürlich die ausgereiftere Lösung, aber auch die komplexere . Das Bereitstellen einer Instanz zum Ausführen von Nexus, das Einrichten von Nexus selbst, das Konfigurieren und Verwalten von Nexus kann für ein so einfaches Problem wie die Verwendung eines einzelnen JARs übertrieben sein. Wenn dieses Szenario - das Hosten von benutzerdefinierten Artefakten - häufig vorkommt, ist ein Repository-Manager sehr sinnvoll.

Das Artefakt direkt in ein öffentliches Repository oder in Maven Central hochzuladen, ist ebenfalls eine gute, aber normalerweise langwierige Lösung. Darüber hinaus ist die Bibliothek möglicherweise überhaupt nicht für Maven aktiviert, was den Prozess erheblich erschwert. Daher ist es keine realistische Lösung, das Artefakt JETZT verwenden zu können.

Damit bleibt die dritte Option - Hinzufügen des Artefakts in der Quellcodeverwaltung und Verwenden eines Maven-Plugins - in diesem Fall das Maven-Install-Plugin, um es lokal zu installieren, bevor der Erstellungsprozess es benötigt . Dies ist bei weitem die einfachste und zuverlässigste verfügbare Option.

2. Installieren Sie Local Jar mit dem m aven-install-plugin

Beginnen wir mit der vollständigen Konfiguration, die zur Installation des Artefakts in unserem lokalen Repository erforderlich ist:

 org.apache.maven.plugins maven-install-plugin 2.5.1  org.somegroup someartifact 1.0 jar ${basedir}/dependencies/someartifact-1.0.jar true    install-jar-lib  install-file  validate   

Lassen Sie uns nun die Details dieser Konfiguration aufschlüsseln und analysieren.

2.1. Die Artefaktinformationen

Die Artefaktinformationen werden als Teil der definiert Element. Die tatsächliche Syntax ist der Deklaration der Abhängigkeit sehr ähnlich - eine groupId , eine ArtefaktId und Versionselemente .

Der nächste Teil der Konfiguration erfordert das Definieren der Verpackung des Artefakts - dies wird als jar angegeben .

Als Nächstes müssen wir den Speicherort der tatsächlich zu installierenden JAR-Datei angeben. Dies kann ein absoluter oder relativer Dateipfad sein, der die in Maven verfügbaren Eigenschaften verwendet . In diesem Fall stellt die Eigenschaft $ {basedir} das Stammverzeichnis des Projekts dar, nämlich den Speicherort, an dem die Datei pom.xml vorhanden ist. Dies bedeutet, dass die Datei someartifact-1.0.jar in einem Verzeichnis / dependencies / unter dem Stammverzeichnis abgelegt werden muss .

Schließlich gibt es noch einige andere optionale Details, die ebenfalls konfiguriert werden können.

2.2. Die Hinrichtung

Die Ausführung der Installationsdatei Ziel ist die gebundene Validate Phase aus dem Standard - Maven Build Lebenszyklus. Bevor Sie versuchen zu kompilieren, müssen Sie die Validierungsphase explizit ausführen:

mvn validate

Nach diesem Schritt funktioniert die Standardkompilierung:

mvn clean install

Sobald die Kompilierungsphase ausgeführt wurde, wird unser Someartifact-1.0.jar korrekt in unserem lokalen Repository installiert, genau wie jedes andere Artefakt, das möglicherweise aus Maven Central selbst abgerufen wurde.

2.3. Generieren eines POM im Vergleich zum Bereitstellen des POM

Die Frage, ob wir eine pom.xml- Datei für das Artefakt bereitstellen müssen oder nicht, hängt hauptsächlich von den Laufzeitabhängigkeiten des Artefakts selbst ab. Einfach ausgedrückt, wenn das Artefakt Laufzeitabhängigkeiten von anderen Jars aufweist, müssen diese Jars auch zur Laufzeit im Klassenpfad vorhanden sein . Mit einem einfachen Artefakt sollte dies kein Problem sein, da es zur Laufzeit wahrscheinlich keine Abhängigkeiten aufweist (ein Blatt im Abhängigkeitsdiagramm).

Die Option generatePom im Ziel der Installationsdatei sollte für diese Art von Artefakten ausreichen:

true

Wenn das Artefakt jedoch komplexer ist und nicht triviale Abhängigkeiten aufweist , müssen diese hinzugefügt werden, wenn diese Abhängigkeiten nicht bereits im Klassenpfad enthalten sind. Eine Möglichkeit, dies zu tun, besteht darin, diese neuen Abhängigkeiten manuell in der POM-Datei des Projekts zu definieren. Eine bessere Lösung besteht darin, eine benutzerdefinierte Datei pom.xml zusammen mit dem installierten Artefakt bereitzustellen :

false ${basedir}/dependencies/someartifact-1.0.pom

Auf diese Weise kann Maven alle Abhängigkeiten des in dieser benutzerdefinierten pom.xml definierten Artefakts auflösen , ohne sie manuell in der Haupt-POM-Datei des Projekts definieren zu müssen.

3. Fazit

In diesem Artikel wird erläutert, wie Sie ein JAR verwenden, das nirgendwo in einem Maven-Projekt gehostet wird, indem Sie es lokal mit dem Maven-Install-Plugin installieren .