Maven: Lebenszyklus vs. Phase vs. Plugin vs. Ziel

Maven: Lebenszyklus vs. Phase vs. Plugin vs. Ziel

Später antworten, nur um ein weiteres Maß an Granularität zu verdeutlichen, das in diesem Thread fehlt: Ausführungen (eines Ziels), die kleinsten Einheiten eines Maven-Builds.

Wir haben also Zyklen aufbauen (im Grunde genommen eine Menge von Aktionen für ein bestimmtes Gesamtziel), die aus Phasen (niedrigere Granularität, ein Zyklusschritt) bestehen. die eine Reihe von konfigurierten Zielen aufrufen können bereitgestellt von bestimmten Plugins. Das heißt, Maven ist (auch) ein Plugin-Executor, jedes Plugin kann ein oder mehrere Ziele bieten. Sie entscheiden dann (auch), welches Ziel mit welcher Phase verbunden ist, und zwar die meiste Zeit im Standardlebenszyklus (ohne das dies der Standard ist). Sie können jedoch auch eine andere Ebene haben: Ausführungen (mit demselben Ziel, mit demselben Plugin oder mit unterschiedlichen Zielen mit unterschiedlichen Plugins).

Ein Bild, das ich vorbereitete, um das Ganze wieder aufzunehmen

Und tatsächlich zeigt Maven dies (seine kleinste Arbeitseinheit) über die eindeutige Zeichenfolge in seinem Build-Protokoll:

plugin-artifactId:plugin-version:plugin-goal (goal-execution-id) @ project-name

Zum Beispiel hätten wir:

[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ sample-project ---

Was in der Tat (durch unterschiedliche Granularitätsebenen) bedeutet:

• während der compile Phase (leider nicht erwähnt)>
• Ich rufe das Maven Compiler-Plugin (artifactId und version)> auf
• Ich rufe sein compile Ziel> auf
• wie durch die Ausführung von default-compile definiert

Dies ist einzigartig, da Sie in der Tat das gleiche Ziel (desselben Plugins) an verschiedene Phasen oder an dieselbe Phase, jedoch in unterschiedlichen Ausführungen (dh mit unterschiedlichen Konfigurationen) gebunden haben könnten. Der maven-compiler-plugin Wird beispielsweise auch während der test-compile - Phase (einer anderen Phase) verwendet, um den Testcode zu kompilieren (über sein testCompile goal) in einer anderen Ausführung (default-testCompile). Sie können auch (mit demselben Plugin und Ziel) einen automatisch generierten Code in einer anderen Phase kompilieren, die durch eine von Ihnen im POM angegebene Ausführung (und möglicherweise eine andere Konfiguration) definiert wurde.

Standardausführungen werden standardmäßig über Maven-Paketbindungen bereitgestellt. Dies bedeutet, dass Maven in bestimmten Phasen bereits bestimmte Ziele (von Standard-Plugins) aufruft (und die Konvention über die Konfiguration erzwingt). Die Ausführungs-IDs dieser Standardaufrufe werden gemäß bestimmten Konventionen definiert.

Dies erklärt auch, warum Sie, wenn Sie ein Standardverhalten (Bindung) eines Maven-Builds wirklich überschreiben möchten, genau dieselbe Ausführungs-ID in Ihrem POM für dasselbe Plugin angeben (überschreiben) müssen. Sie können beispielsweise die Kompilierung überspringen, indem Sie einfach eine Ausführung des maven-compiler-plugin Mit derselben default-compile - ID definieren, die jedoch an eine nicht vorhandene (oder eine leere) Phase gebunden ist.

Um es kurz zu machen: Eine Ausführung teilt Maven mit, welche Ziele mit welcher Konfiguration in welcher Phase ausgeführt werden sollen.

Einige Ausführungen werden standardmäßig bereitgestellt (Standardbindungen), was erklärt, warum die maven minimal pom von nur 6 Zeilen bereits viel können (kompilieren, testen, packen, etc.): Ziele von Standard-Plugins in bestimmten Phasen ausführen: Konvention über Konfiguration. Dann können Sie über die pom.xml - Konfiguration stuff (Ausführungen) zum Build hinzufügen oder das Verhalten bereits konfigurierter Plugins beeinflussen (in diesem Fall kein Abschnitt executions , aber nur configuration würde ausreichen).

Ja, Sie können Build-Zyklen (und deren Phasen) überspringen und Ziele (von Plugins) direkt aufrufen. Stellen Sie sich Folgendes vor:

mvn compiler:compile
mvn compiler:testCompile
mvn surefire:test
mvn jar:jar

(HINWEIS: Sie können Inline auch in nur einem Aufruf aufrufen.)

Hier kompilieren wir App-Code, testen Code, führen Tests und Pakete aus: Stellen Sie sich vor, wie manuell, fehleranfällig, sich wiederholend und zeitaufwändig dies sein würde. Konvention über Konfiguration hilft uns: Maven führt Build-Lebenszyklen und Phasen ein. Der voreingestellte Lebenszyklus (dh der voreingestellte Lebenszyklus ohne Namen) bietet eine Reihe von Phasen, die auf bewährten Praktiken und Konventionen (dem Mantra von Maven) basieren.
Wenn Sie dasselbe wie oben erreichen möchten, führen Sie einfach Folgendes aus: mvn package Und das Projekt wird automatisch kompiliert, getestet und gepackt. Wie? Plugins aufrufen. Das heißt, Phasen sind sinnvolle und konfigurierbare Plugins (Ziele). Um es noch standardisierter zu machen, ruft Maven für jede Phase zuerst eine vorangehende Phase auf, so dass z. Wenn Sie testen möchten, können Sie sicher sein, dass Sie zuerst kompilieren.

p.s. Beachten Sie, dass bei der Angabe mehrerer Ziele für dasselbe execution im Build-Protokoll immer noch zwei verschiedene Ausführungen (mit derselben ID) für die beiden unterschiedlichen Ziele angezeigt werden (daher immer noch eindeutiges Tupel).

Gutschrift an Sandeep Jindal und Premraj (von hier aus Was sind Maven Ziele und Phasen und was ist ihr Unterschied? ). Ihre Erklärung hilft mir zu verstehen.

Ich habe hier einige vollständige Codebeispiele und einige einfache Erklärungen erstellt https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/ . Ich denke, es kann anderen helfen, etwas zu verstehen und direkt zu versuchen.

Kurz gesagt, Sie sollten nicht versuchen, alle drei auf einmal zu verstehen. Zuerst sollten Sie die Beziehung in diesen Gruppen verstehen:

• Lebenszyklus vs Phase
• Plugin vs Goal

1. Lebenszyklus vs Phase

Lebenszyklus ist eine Sammlung von Phasen in der Reihenfolge, siehe hier - Lebenszyklus-Referenzen . Wenn Sie eine Phase aufrufen, werden auch alle Phasen davor aufgerufen .

Zum Beispiel hat der saubere Lebenszyklus 3 Phasen ( Vorreinigung, Reinigung, Nachreinigung ).

mvn clean

Es wird Pre-Clean und Clean aufgerufen.

2. Plugin vs Goal

Ziel ist wie eine Aktion im Plugin . Wenn also das Plugin eine Klasse ist, ist das Ziel eine Methode.

du kannst ein Ziel wie dieses nennen:

mvn clean:clean

Dies bedeutet "Nenne das saubere Ziel im sauberen Plugin" (Nichts bezieht sich auf die saubere Phase hier. Lass dich nicht vom Wort "reinigen" verwirren, sie sind nicht gleich! Siehe die vollständige Erklärung in meinem Link oben)

3. Nun die Beziehung zwischen Phase & Ziel:

Phase kann (vor) Links zu Ziel (s) enthalten. Zum Beispiel Normalerweise ist die Clean-Phase mit dem Clean-Ziel verknüpft. Wenn Sie diesen Befehl aufrufen:

mvn clean

Es wird die Pre-Clean-Phase und die Clean-Phase genannt, die mit dem Clean: Clean-Ziel verknüpft ist.

Es ist fast das gleiche wie:

mvn pre-clean clean:clean

Und nachträglich ein anderes Diagramm

• Lebenszyklen als gelbe Rechtecke
• Phasen von Lebenszyklen als blaue Rechtecke mit "aufrufbar" Phasen in dunklerem Blau (dh die Phasen mit Hypenierung werden normalerweise nicht von aufgerufen die Befehlszeile, da sie möglicherweise nicht so gestaltet ist, dass das Projekt in einem genau definierten Zustand bleibt).
• Tore als blaue Raute. Die gezeigte Assoziation/Bindung "Phase -> Ziel" ist diejenige des Verpackungsmodus "Gefäß" . An jede Phase können Ziele gebunden sein. Dies gilt natürlich für jeden Lebenszyklus, obwohl Bindungen nur für den "Standard" -Lebenszyklus angezeigt werden.
• Plugins als grau beschnittene Rechtecke. Plugins bieten die Ziele, die an die Phasen gebunden werden können.

Quelle: http://www.codetab.org/Apache-maven-tutorial/ , das ist wirklich ein gutes Tutorial

Lebenszyklen, Lebenszyklusphasen, Plugins und Plugin-Ziele bilden den Kern von Maven.

• Der Maven-Befehl mvn kann nur die Lifecycle-Phase oder das Plugin-Ziel als Argument akzeptieren.
• Maven wird mit drei Lebenszyklen geliefert - Standard, sauber und Standort.
• Jeder Lebenszyklus besteht aus Lebenszyklusphasen und insgesamt gibt es 28 Phasen - Standard 21 ( validieren, ..., kompilieren, ..., paketieren, ..., installieren, implementieren), bereinigen 3 ( Vorreinigung, Reinigung, Nachreinigung) und Standort 4 ( Pre-Site, Site, Post-Site, Site-Deployment).
• wenn eine Lebenszyklusphase mit dem Befehl mvn aufgerufen wird, werden alle vorhergehenden Phasen nacheinander ausgeführt.
• lebenszyklusphasen haben für sich genommen keine Fähigkeiten, um eine Aufgabe zu erledigen, und sie verlassen sich auf Plugins, um die Aufgabe auszuführen.
• je nach Projekt und Verpackungstyp verknüpft Maven verschiedene Plugin-Ziele mit Lebenszyklusphasen und Zielen, die die ihnen übertragene Aufgabe erfüllen.

Wenn wir " mvn package" in einem Java Project ausführen, bindet Maven Plugin-Ziele an Lebenszyklusphasen, wie in der nächsten Abbildung gezeigt.

Also, um es ein wenig weiter zu erklären, wie es umrissen ist hier

Maven-Builds sind in folgende Lebenszyklen unterteilt:

• reinigen
• build (Standard)
• seite? ˅

Jeder dieser Zyklen ist in Phasen unterteilt. Zum Beispiel ist der Build in folgende Phasen unterteilt:

• ressourcen vorbereiten
• kompilieren
• paket
• installieren

Phasen haben Ziele, die vor vor oder nach nach einer Phase ausgeführt werden sollen , zum Beispiel:

• vorreinigung - wird vor der Reinigungsphase ausgeführt
• nachreinigung - wird nach der Reinigungsphase ausgeführt

Sie können Ziele als zusätzliche "eingefügte" Phasen anzeigen, wenn Sie möchten. Lesen Sie hier oder schauen Sie @ Gerolds Antwort für Details.

Lebenszyklus gegen Phasen: Life Cycle ist eine Sammlung von phases. Wenn Sie eine Phase aufrufen, werden auch alle vorhergehenden Phasen aufgerufen. Maven kommt mit 3 eingebauten Build-Lebenszyklen als:

1. Clean Lifecycle - Bereinigen des Projekts (für einen Neuaufbau und eine Bereitstellung)
2. Standard-/Build-Lebenszyklus - Hiermit wird die vollständige Bereitstellung des Projekts durchgeführt
3. Site Lifecycle - Hiermit wird die Java Dokumentation des Projekts erstellt.

Der saubere Lebenszyklus besteht aus drei Phasen: Vorreinigung, Reinigung und Nachreinigung. Die Phasen der Standard- und Standortlebenszyklen stimmen mit den in der Abbildung gezeigten überein.