Maven Deploy auf Nexus

Ina previous article habe ich erläutert, wie ein Maven-Projekt lokal ein Drittanbieter-JAR installieren kann, das noch nicht in Maven Central (oder einem der anderen großen und öffentlich gehosteten Repositorys) bereitgestellt wurde.

Diese Lösung sollte nur in kleinen Projekten angewendet werden, in denen die Installation, der Betrieb und die Wartung eines vollständigen Nexus-Servers möglicherweise zu teuer sind. Wenn jedoch ein Projekt wächst,

Nexus wird schnell zur einzigen echten und ausgereiften Option für das Hosten von Artefakten von Drittanbietern sowie für die Wiederverwendung interner Artefakte in Entwicklungsströmen.

Dieser Artikel zeigt, wie die Artefakte eines Projektsto Nexus, with Maven bereitgestellt werden.

Damit Maven die in derpackage-Phase des Builds erstellten Artefakte bereitstellen kann, muss er die Repository-Informationen definieren, in denen die gepackten Artefakte bereitgestellt werden sollen, und zwar über das%(t1)s-Element:

Ein gehostetes, öffentlichesSnapshots-Repository ist im Nexus sofort einsatzbereit, sodass Sie keine weiteren Elemente erstellen oder konfigurieren müssen. Mit Nexus können Sie auf einfache Weise die URLs der gehosteten Repositorys ermitteln. Jedes Repository zeigt auf der RegisterkarteSummary den genauen Eintrag an, der in<distributionManagement> des Projekt-POMs hinzugefügt werden soll.

Standardmäßig verwaltet Maven den Bereitstellungsmechanismus übermaven-deploy-plugin - dies wird derdeployment-Phase des Standard-Maven-Lebenszyklus zugeordnet:

maven-deploy-plugin ist eine praktikable Option für die Bereitstellung von Artefakten eines Projekts in Nexus, wurde jedoch nicht entwickelt, um die Vorteile von Nexus voll auszuschöpfen. Aus diesem Grund hat Sonatype ein Nexus-spezifisches Plugin erstellt - dasnexus-staging-maven-plugin -, das tatsächlich entwickelt wurde, um die erweiterten Funktionen von Nexus voll auszunutzen - Funktionen wie Staging.

Obwohl wir für einen einfachen Bereitstellungsprozess keine Staging-Funktionalität benötigen, werden wir dieses benutzerdefinierte Nexus-Plugin weiterentwickeln, da es mit dem klaren Zweck erstellt wurde, gut mit Nexus zu kommunizieren.

Der einzige Grund für die Verwendung vonmaven-deploy-plugin besteht darin, die Option offen zu halten, in Zukunft eine Alternative zu Nexus zu verwenden - beispielsweise einArtifactory-Repository. Im Gegensatz zu anderen Komponenten, die sich möglicherweise während des gesamten Lebenszyklus eines Projekts ändern, ist es jedoch sehr unwahrscheinlich, dass sich der Maven Repository Manager ändert, sodass keine Flexibilität erforderlich ist.

Der erste Schritt bei der Verwendung eines anderen Bereitstellungs-Plugins in der Bereitstellungsphase besteht darin, die vorhandene Standardzuordnung zu deaktivieren:

Nun können wir definieren:

Dasdeploy-Ziel des Plugins wird derdeploy-Phase des Maven-Builds zugeordnet.

Beachten Sie auch, dass wir, wie bereits erwähnt, keine Staging-Funktionalität für eine einfache Bereitstellung von-SNAPSHOT Artefakten in Nexus benötigen, sodass diese über das<skipStaging>-Element vollständig deaktiviert wird.

Standardmäßig enthält das Bereitstellungsziel den Staging-Workflow, der für Release-Builds empfohlen wird.

Die Bereitstellung auf Nexus erfolgt mitsecured operation - und eindeployment-Benutzer ist zu diesem Zweck auf jeder Nexus-Instanz sofort verfügbar.

Das Konfigurieren von Maven mit den Anmeldeinformationen diesesdeployment-Benutzers, damit es korrekt mit Nexus interagieren kann, kann inpom.xml des Projekts nicht durchgeführt werden. Dies liegt daran, dass die Syntax derpom dies nicht zulässt, ganz zu schweigen von der Tatsache, dass diepom möglicherweise ein öffentliches Artefakt sind und daher nicht für die Speicherung von Anmeldeinformationen geeignet sind.

Die Anmeldeinformationen des Servers müssen in den globalen Mavensetting.xml definiert werden:

Der Server kann auch so konfiguriert werden, dass die schlüsselbasierte Sicherheit anstelle von unformatierten und Nur-Text-Anmeldeinformationen verwendet wird.

Das Durchführen des Bereitstellungsprozesses ist eine einfache Aufgabe:

Das Überspringen von Tests ist im Kontext eines Bereitstellungsjobs in Ordnung, da dieser Job der letzte Job vondeployment pipeline für das Projekt sein sollte.

Ein gängiges Beispiel für eine solche Bereitstellungspipeline wäre eine Abfolge von Jenkins-Jobs, die jeweils nur dann ausgelöst werden, wenn sie erfolgreich abgeschlossen wurden. Daher liegt es in der Verantwortung der vorherigen Jobs in der Pipeline, alle Testsuiten aus dem Projekt auszuführen. Zum Zeitpunkt der Ausführung des Bereitstellungsjobs sollten alle Tests bereits bestanden sein.

Wenn ein einzelner Befehl ausgeführt wird, können Tests aktiv gehalten werden, bevor die Phase vondeploymentausgeführt wird:

Dies ist eine einfache, aber sehr effektive Lösung für die Bereitstellung von Maven-Artefakten für Nexus.

Es ist auch etwas eigensinnig -nexus-staging-maven-plugin wird anstelle der Standardeinstellungmaven-deploy-plugin verwendet; Die Staging-Funktionalität ist deaktiviert usw. Diese Auswahlmöglichkeiten machen die Lösung einfach und praktisch.

Die potenzielle Aktivierung der vollständigen Staging-Funktionalität kann Gegenstand eines zukünftigen Artikels sein.

Abschließend werden wir den Freigabeprozess im nächsten Artikel erläutern.