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 validateNach diesem Schritt funktioniert die Standardkompilierung:
mvn clean installSobald 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:
trueWenn 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.pomAuf 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 .