Lokales Glas mit Maven installieren

1. Das Problem und die Optionen

Maven ist ein sehr vielseitiges Werkzeug und die 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, kann riskant sein, da es möglicherweise nicht vorhanden ist, wenn Sie es benötigen.

Wenn dies passiert, gibt es einige Möglichkeiten:

beißen das Geschoss und installieren Sie eine vollwertige Repository-Verwaltung

Lösung such wie Nexus ** Versuchen Sie, das Artefakt in ein seriöseres Publikum zu laden

Repositories Installieren Sie das Artefakt lokal ** mithilfe eines Maven-Plugins

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 Warten dieser Instanz kann für ein so einfaches Problem wie die Verwendung einer einzelnen Dose ein Übermaß sein. Wenn dieses Szenario, in dem benutzerdefinierte Artefakte gehostet werden, häufig vorkommt, ist ein Repository-Manager durchaus sinnvoll.

Das Hochladen des Artefakts in ein öffentliches Repository oder direkt in Maven Central ist ebenfalls eine gute Lösung. In der Regel ist dies jedoch eine gute Lösung]. Außerdem ist die Bibliothek möglicherweise überhaupt nicht Maven-fähig, was den Prozess umso schwieriger macht. Daher ist es keine realistische Lösung, das Artefakt JETZT verwenden zu können.

Die dritte Option bleibt übrig - Hinzufügen des Artefakts in der Quellcodeverwaltung und Verwenden eines Maven-Plugins - in diesem Fall the maven-install-plugin auf Installieren Sie es lokal, bevor der Buildprozess es benötigt . Dies ist bei weitem die einfachste und zuverlässigste verfügbare Option.

2. Lokales Jar mit dem maven-install-plugin installieren

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

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-install-plugin</artifactId>
   <version>2.5.1</version>
   <configuration>
      <groupId>org.somegroup</groupId>
      <artifactId>someartifact</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <file>${basedir}/dependencies/someartifact-1.0.jar</file>
      <generatePom>true</generatePom>
   </configuration>
   <executions>
      <execution>
         <id>install-jar-lib</id>
         <goals>
            <goal>install-file</goal>
         </goals>
         <phase>validate</phase>
      </execution>
   </executions>
</plugin>

Lassen Sie uns nun die Details dieser Konfiguration analysieren und analysieren.

2.1. Die Artefaktinformationen

Die Artefaktinformationen werden als Teil des Elements <configuration> definiert. Die tatsächliche Syntax ist der Deklaration der Abhängigkeit sehr ähnlich - einem groupId -, artifactId - und version -Element.

Der nächste Teil der Konfiguration erfordert die Definition des packaging des Artefakts - dies wird als jar angegeben.

Als Nächstes müssen Sie den Speicherort der eigentlichen JAR-Datei angeben, die installiert werden soll. Dies kann ein absoluter Dateipfad sein oder er kann relativ sein. Verwenden Sie dazu https://cwiki.apache.org/confluence/display/MAVEN/Maven Properties Guide[Eigenschaften]in Maven verfügbar. In diesem Fall stellt die Eigenschaft $ \ {basedir} den Stamm des Projekts dar, dh den Ort, an dem sich die Datei pom.xml befindet. Dies bedeutet, dass die Datei someartifact-1.0.jar in einem Verzeichnis /dependencies/ unter dem Stammverzeichnis gespeichert werden muss.

Schließlich gibt es noch einige andere http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html Optionale Details, die ebenfalls konfiguriert werden können.

2.2. Die Hinrichtung

Die Ausführung des install-file -Ziels ist an die validate -Phase des Standard-Maven ( http://maven.apache.org/guides/introduction/introduction-in-the-lifecycle.html ]gebunden. Daher müssen Sie vor dem Kompilieren die Validierungsphase explizit ausführen:

mvn validate

Nach diesem Schritt wird die Standardzusammenstellung funktionieren:

mvn clean install

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

2.3. Generieren eines pom vs. Bereitstellung 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 für andere Jars aufweist, müssen diese zur Laufzeit auch im Klassenpfad vorhanden sein. Mit einem einfachen Artefakt sollte dies kein Problem sein, da es zur Laufzeit wahrscheinlich keine Abhängigkeiten gibt (ein Blatt im Abhängigkeitsgraphen).

Die Option generatePom im Ziel install-file sollte für diese Art von Artefakten ausreichen:

<generatePom>true</generatePom>

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 ist die Bereitstellung einer benutzerdefinierten pom.xml -Datei zusammen mit dem installierten Artefakt:

<generatePom>false</generatePom>
<pomFile>${basedir}/dependencies/someartifact-1.0.pom</pomFile>

Dadurch kann Maven alle Abhängigkeiten des in dieser benutzerdefinierten pom.xml definierten Artefakts auflösen, ohne sie manuell in der Pom-Hauptdatei des Projekts definieren zu müssen.

3. Fazit

In diesem Artikel wird beschrieben, wie ein Jar verwendet wird, der nirgendwo in einem Maven-Projekt gehostet wird, indem er lokal mit dem maven-install-plugin installiert wird.

TOC