Spezielle Variablen

• Es gibt einige speziell definierte und referenzierbare Variablen, die nicht im Projektmodell enthalten sind.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <build>
    ...
          <target>
            <echo>project.basedir = ${project.basedir}</echo>
            <echo>project.baseUri = ${project.baseUri}</echo>
            <echo>maven.build.timestamp = ${maven.build.timestamp}</echo>
          </target>
    ...
  </build>
</project>

Ausführungsergebnis

     [echo] project.basedir = F:\tmp\maven\hello
     [echo] project.baseUri = file:///F:/tmp/maven/hello/
     [echo] maven.build.timestamp = 2020-03-04T13:45:10Z

--Die folgenden drei Variablen sind implizit als ** Spezielle Variablen ** definiert. - project.basedir

• Ordner des Projekts selbst
  • project.baseUri --project.basedir wird durch URI dargestellt
  • maven.build.timestamp
• Laufzeitstempel (UTC)

Geben Sie das Format des Zeitstempels an

• Indem Sie die Eigenschaft maven.build.timestamp.format deklarieren, können Sie das Format von maven.build.timestamp beliebig angeben.
• Das Format des Formats folgt SimpleDateFormat.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <maven.build.timestamp.format>yyyy/MM/dd HH:mm:ss</maven.build.timestamp.format>
  </properties>
  
  <build>
    ...
            <echo>maven.build.timestamp = ${maven.build.timestamp}</echo>
    ...
  </build>
</project>

Ausführungsergebnis

     [echo] maven.build.timestamp = 2020/03/04 13:49:49+00:00

Eigentum

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <foo>FOO!!</foo>
    <fizz.buzz>FIZZ.BUZZ!?</fizz.buzz>
    <hoge-fuga>HOGE-FUGA??</hoge-fuga>
  </properties>
  
  <build>
    ...
            <echo>foo = ${foo}</echo>
            <echo>fizz.buzz = ${fizz.buzz}</echo>
            <echo>hoge-fuga = ${hoge-fuga}</echo>
            <echo>FOO = ${FOO}</echo>
    ...
  </build>
</project>

Ausführungsergebnis

     [echo] foo = FOO!!
     [echo] fizz.buzz = FIZZ.BUZZ!?
     [echo] hoge-fuga = HOGE-FUGA??
     [echo] FOO = ${FOO}

• Sie können Ihre eigenen Variablen (Eigenschaften) im Tag "" deklarieren. ---und . können im Namen enthalten sein
• Fallempfindlich

Umgebungsvariable

xml.pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <build>
    ...
            <echo>hoge = ${env.hoge}</echo>
            <echo>Hoge = ${env.Hoge}</echo>
            <echo>HOGE = ${env.HOGE}</echo>
    ...
  </build>
</project>

Ausführungsergebnis(Unter Windows)

> set Hoge=Hello

> mvn antrun:run
...
     [echo] hoge = ${env.hoge}
     [echo] Hoge = ${env.Hoge}
     [echo] HOGE = Hello
...

Ausführungsergebnis(Unter Linux)

$ export Hoge=Hello

$ mvn antrun:run
...
     [echo] hoge = ${env.hoge}
     [echo] Hoge = Hello
     [echo] HOGE = ${env.HOGE}

• Sie können auf den Wert der Umgebungsvariablen des Betriebssystems mit "$ {env. Name der Umgebungsvariablen}" verweisen
• Unter Windows wird der Variablenname "env" in Großbuchstaben ** normalisiert ** --Das heißt, selbst wenn der Name der unter Windows deklarierten Umgebungsvariablen "Pfad" lautet, muss er in Großbuchstaben als "$ {env.PATH}" geschrieben werden, wenn auf pom.xml verwiesen wird. ――Es ist nur eine Geschichte unter Windows, und wenn Sie unter Linux laufen, geben Sie sie mit demselben Namen an, bei dem zwischen Groß- und Kleinschreibung unterschieden wird. ―― Nun, ich denke, dass es üblich ist, Umgebungsvariablen in Großbuchstaben zu deklarieren. Wenn Sie also pom.xml in Großbuchstaben schreiben, haben Sie keinen Unfall.

Systemeigenschaften

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  
  <properties>
    <foo.bar>foo-bar</foo.bar>
    <fizz.buzz>fizz-buzz</fizz.buzz>
  </properties>

  <build>
    ...
            <echo>java.version = ${java.version}</echo>
            <echo>java.vm.vendor = ${java.vm.vendor}</echo>
            <echo>foo.bar = ${foo.bar}</echo>
            <echo>fizz.buzz = ${fizz.buzz}</echo>
    ...
  </build>
</project>

Ausführungsergebnis

> mvn antrun:run -Dfoo.bar=FOO-BAR
...
     [echo] java.version = 11.0.6
     [echo] java.vm.vendor = AdoptOpenJDK
     [echo] foo.bar = FOO-BAR
     [echo] fizz.buzz = fizz-buzz

• Sie können auf Java-Systemeigenschaften (Werte, die mit "System.getProperties ()" abgerufen werden können) verweisen, wie sie mit "$ {Name der Systemeigenschaft}" angegeben sind. --Wenn eine Eigenschaft mit demselben Namen in "" deklariert ist, hat der in der Systemeigenschaft angegebene Wert Vorrang.

Repository

• Eine der wichtigsten Komponenten von Maven ist ** Repository ** --Maven speichert und verwaltet die Artefakte des erstellten Projekts im Repository.
• Das eigentliche Artefakt ist normalerweise eine JAR-Datei, die durch Erstellen des Projekts erstellt wurde.

Zentrales Repository

• Es gibt zwei Arten von Repositorys
• Lokales Repository
• Remote-Repository
• Standardmäßig wird ein Remote-Repository namens Central Repository (https://repo.maven.apache.org/maven2) verwendet.
• Wenn Sie den obigen Link in Ihrem Browser öffnen, sehen Sie, dass es verschiedene Unterverzeichnisse gibt.
• Wenn Sie dem Verzeichnis richtig folgen, erreichen Sie endlich das Verzeichnis, in dem sich die JAR-Datei befindet.
• Zum Beispiel hat this Version 5.2.4.RELEASE des Kerns von Spring Framework. Werden Sie ein Verzeichnis ―― Wie Sie sehen können, enthält das zentrale Repository verschiedene OSS-Artefakte aus der ganzen Welt.
• Das zentrale Repository wird von einer Firma namens Sonatype verwaltet.
• Jeder kann sein OSS im zentralen Repository veröffentlichen, indem er sich bewirbt (kostenlos).
• Die Bewerbung ist jedoch in englischer Sprache
• Die Anwendungseinheit gilt für jede groupId
• Wenn Sie nach "Maven Central Repository Publishing Procedure" suchen, finden Sie verschiedene Kommentarartikel.
• Da es schwierig ist, das direkt im Browser geöffnete zentrale Repository zu durchsuchen, verwenden Sie normalerweise eine Suchseite wie Maven-Repository: Suchen / Durchsuchen / Durchsuchen.
• Oder beziehen Sie sich auf die Informationen auf der offiziellen Seite der Bibliothek, die Sie verwenden möchten.

Abhängigkeitsauflösung

• Eine der leistungsstarken Funktionen von Maven ist die Auflösung von Abhängigkeiten.
• In pom.xml können die vom Projekt verwendeten Artefakte wie folgt als Abhängigkeiten definiert werden:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>
</project>

--<Abhängigkeit>unter<Abhängigkeiten>zeigt auf ein Artefakt

• Wenn Sie dies so deklarieren, lädt Maven die mit "<Abhängigkeiten>" deklarierten Artefakte automatisch aus dem Remote-Repository herunter, wenn Sie das Projekt erstellen und sie Ihrem Klassenpfad hinzufügen. ―― Mit anderen Worten, Sie können sich die Mühe sparen, die Bibliothek von Hand zu löschen.
• Darüber hinaus enthalten die im Repository gespeicherten Artefakte auch eine eigene pom.xml. --Wenn in der pom.xml des im Projekt angegebenen Artefakts mehr "<Abhängigkeiten>" vorhanden sind, lädt Maven diese abhängigen Artefakte automatisch ebenfalls herunter. Mit anderen Worten, es ist ein Mechanismus, der alle Abhängigkeiten vom Imozuru-Ausdruck auflöst. --Maven erleichtert dank dieses Mechanismus die Verwaltung abhängiger Bibliotheken erheblich.
• Apache Ant, der Vorgänger von Maven, war sehr schmerzhaft, weil er Abhängigkeiten manuell verwalten musste.
• Dieser Mechanismus wird auch in Gradle verwendet, einem Nachzügler von Maven.

Lokales Repository

• Aus Remote-Repositorys heruntergeladene Artefakte und Metainformationen (z. B. pom.xml) werden lokal auf dem Computer zwischengespeichert, auf dem Maven ausgeführt wird.
• Dieses Cache-Ziel heißt ** lokales Repository ** ――Wenn Sie bei jedem Erstellen auf das Remote-Repository zugreifen, dauert es lange und Sie können nicht in einer Umgebung erstellen, in der das Netzwerk nicht verfügbar ist.
• Deshalb soll Maven zuerst das lokale Repository durchsuchen.
• Findet das Remote-Repository, wenn das gewünschte Artefakt nicht im lokalen Repository vorhanden ist.
• Wenn Sie ein Artefakt in einem Remote-Repository finden, laden Sie es herunter und speichern Sie es in Ihrem lokalen Repository.
• Auf diese Weise können Sie ein Projekt ohne Netzwerkzugriff erstellen, da Sie erst ab dem zweiten Mal auf das lokale Repository verweisen müssen.
• Der Speicherort des lokalen Repositorys ist standardmäßig "% USERPROFILE% \ .m2 \ repository"
• Für Linux-Betriebssystem "$ HOME / .m2 / repository"
• Im lokalen Repository zwischengespeicherte Artefakte bleiben erhalten, wenn nichts unternommen wird
• Wenn es keinen Grund gibt, z. B. wenn der Speicherplatz knapp wird, muss er nicht gelöscht werden.

Privater Bereich

• Sie können Ihr eigenes Remote-Repository mit einer OSS-Anwendung namens Nexus Repository OSS erstellen. --Nexus wird von Sonatype entwickelt, das das zentrale Repository verwaltet.
• Es gibt eine kostenpflichtige Version und eine kostenlose OSS-Version
• Wenn Sie beispielsweise ein Artefakt haben, das Sie nur in Ihrem Unternehmen freigeben möchten, können Sie es problemlos als privates Repository verwenden, indem Sie einen Nexus-Server im Intranet erstellen.
• Das zu verwendende Remote-Repository kann in pom.xml wie folgt angegeben werden:
• Hostname und Portnummer müssen entsprechend der tatsächlichen Umgebung angepasst werden

Pom, wenn ein Remote-Repository angegeben ist.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <repositories>
    <repository>
      <id>my-private-repository</id>
      <name>My Private Repository</name>
      <url>http://private.repository.host/repository</url>
      <layout>default</layout>
    </repository>
  </repositories>
</project>

• Darüber hinaus fungiert Nexus auch als Proxy für andere Remote-Repositorys. ―― Nehmen wir zum Beispiel an, Sie haben die folgende Konfiguration
• Erstellen Sie das Nexus-Repository als Proxy für das zentrale Repository
• Setzen Sie das Nexus-Repository als Remote-Repository in pom.xml
• Wenn das Projekt abhängige Artefakte aufweist, durchsucht Maven zuerst das lokale Repository. --Wenn es sich nicht im lokalen Repository befindet, suchen Sie nach dem Nexus-Repository, das Sie als Remote-Repository angegeben haben. --Nexus durchsucht das zentrale Repository, wenn es sich nicht im Nexus-Repository befindet --Und es gibt die aus dem zentralen Repository heruntergeladenen Artefakte an Maven zurück.
• Zu diesem Zeitpunkt speichert das Nexus-Repository die aus dem zentralen Repository heruntergeladenen Artefakte intern zwischen.
• Wenn eine Suchanforderung für dasselbe Artefakt eingeht, wird das zwischengespeicherte Artefakt zurückgegeben.
• Dies ermöglicht es, den Netzwerkverkehr zu reduzieren oder Abhängigkeiten aufzulösen, indem eine Verbindung zum Nexus-Repository im Intranet hergestellt wird, auch wenn das Internet aufgrund eines Fehlers nicht verbunden ist.

** Proxy-Bild **

Plug-in (einfach)

In Maven erfolgt die gesamte Verarbeitung über das ** Plugin **.

Der Prozess zum Kompilieren von Java-Quellcode wird beispielsweise von maven-compiler-plugin bereitgestellt.

Eine Liste der vom Maven-Projekt selbst bereitgestellten Basis-Plugins finden Sie unter Maven - Verfügbare Plugins.

Plugin Ziel

• Einzelne Aufgaben (Prozesse), die im Plug-In definiert sind, werden als ** Ziel ** bezeichnet.
• Beziehen Sie sich auf die Dokumentation jedes Plug-Ins, um herauszufinden, welche Ziele das Plug-In hat, das Sie verwenden möchten.
• In [maven-jdeps-plugin] definierte Ziele (https://maven.apache.org/plugins/maven-jdeps-plugin/#Goals_Overview) - jdkinternals - test-jdkinternals
• In [maven-jar-plugin] definierte Ziele (https://maven.apache.org/plugins/maven-jar-plugin/#Goals_Overview) - jar - test-jar

Wie man ein Ziel ausführt

Es gibt zwei Möglichkeiten, um die Ziele eines Plug-Ins auszuführen.

1. Geben Sie direkt in der Befehlszeile an und führen Sie aus
2. In Verbindung mit der Phase ausführen

Die Methode zur Verknüpfung mit der zweiten Phase wird aufgehoben, und die Methode zur direkten Angabe von 1 wird zuerst bestätigt.

Vollqualifizierte Namensspezifikation

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Führen Sie das JDEPS-Plug-In aus

> mvn org.apache.maven.plugins:maven-jdeps-plugin:3.1.2:jdkinternals
...
classes -> java.base
   example          -> java.io            java.base
   example          -> java.lang          java.base
...

• Irgendwie werden lange Argumente an den Befehl mvn übergeben
• Dies gibt den vollständig qualifizierten Namen und den Zielnamen des vorherigen [maven-jdeps-plugin] an (https://maven.apache.org/plugins/maven-jdeps-plugin/).
• Im Format sieht es aus wie ": " --<voll qualifizierter Name>ist hier org.apache.maven.plugins: maven-jdeps-plugin: 3.1.2,
• "" wird zu "jdkinternals"
• Wenn Sie einen vollständig qualifizierten Namen angeben, wird die JAR-Datei des Plug-Ins basierend auf diesen Informationen aus dem Repository abgerufen und das Ziel ausgeführt.

Präfixspezifikation (wenn keine Plug-In-Einstellung vorhanden ist)

――Da es schwierig ist, jedes Mal den vollständig qualifizierten Namen einzugeben, können Sie auch die folgende Beschreibung weglassen.

Wenn weggelassen

> mvn jdeps:jdkinternals
...
classes -> java.base
   example          -> java.io            java.base
   example          -> java.lang          java.base
...

• So geben Sie das Format "<Präfix>: " an
• Ob es sich um eine vollständig qualifizierte Namensspezifikation oder eine Präfixspezifikation handelt, wird durch die Anzahl der Doppelpunkte (:) [^ 4] unterschieden.
• Wenn es drei : gibt, geben Sie mit dem vollständig qualifizierten Namen groupId: artefaktId: version: target an. --Wenn es zwei : gibt, geben Sie groupId: ArtefaktId: Ziel ohne die Versionsnummer an. --Wenn es nur ein : gibt, geben Sie mit dem Präfix Präfix: Ziel an
• Wenn ein Präfix angegeben wird, wird der vollständig qualifizierte Name wie folgt aufgelöst.
• Lassen Sie zuerst groupdId eine der folgenden sein:
  • org.apache.maven.plugin
  • org.codehaus.mojo
• Schauen Sie sich als nächstes die Metadaten (maven-metadata.xml) für jede groupId an
• org.apache.maven.plugin maven-metadata.xml
• org.codehaus.mojo maven-metadata.xml
• Wenn Sie sich den Inhalt von "maven-metadata.xml" ansehen, können Sie sehen, dass die Entsprechung des Präfixes für jede "Artefakt-ID" aufgeführt ist.

xml:org.apache.maven.Plugin Maven-metadata-xml

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <plugins>
    <plugin>
      <name>Apache Maven ACR Plugin</name>
      <prefix>acr</prefix>
      <artifactId>maven-acr-plugin</artifactId>
    </plugin>
    ...
    <plugin>
      <name>Apache Maven JDeps Plugin</name>
      <prefix>jdeps</prefix>
      <artifactId>maven-jdeps-plugin</artifactId>
    </plugin>
    ...
  </plugins>
</metadata>

--Finden Sie in dieser maven-metadata.xml eine Übereinstimmung, die dem in der Befehlszeile angegebenen Präfix entspricht, und setzen Sie diese <artifactId> auf artefaktId.

• Da das in der Befehlszeile angegebene Präfix "jdeps" ist, wird "maven-jdeps-plugin" zu "artefakt-ID". --Überprüfen Sie als nächstes die Metadaten (maven-metadata.xml) für jede Artefakt-ID
• maven-metadata.xml des maven-jdeps-plugins

maven-jdeps-Plugin Maven-metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jdeps-plugin</artifactId>
  <versioning>
    <latest>3.1.2</latest>
    <release>3.1.2</release>
    <versions>
      <version>3.0.0</version>
      <version>3.1.0</version>
      <version>3.1.1</version>
      <version>3.1.2</version>
    </versions>
    <lastUpdated>20190619052916</lastUpdated>
  </versioning>
</metadata>

• Setzen Sie den in der Release-Version (<release>) festgelegten Wert auf version --Wenn es keine Release-Version gibt, soll die neueste Version (<latest>) [^ 5] version sein.
• Die oben ermittelten groupId , artefaktId und version sind vollständig qualifizierte Namen.
  • groupId : org.apache.maven.plugin
  • artifactId : maven-jdeps-plugin
  • version : 3.1.2

[^ 4]: Genau genommen wird eine Spezifikation wie compiler :::: compile auch als Präfixspezifikation beurteilt, aber hier wird die Anzahl der Doppelpunkte aus Gründen der Klarheit verwendet (für Details [MojoDescriptorCreator-Implementierung] Siehe](https://github.com/apache/maven/blob/maven-3.6.3/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoDescriptorCreator.java#L141) )

[^ 5]: <release> ist die neueste Version in der Release-Version, während <latest> auf die neueste Version verweist, einschließlich Snapshots.

Stellen Sie das Plug-In explizit ein

-In der Methode von ↑ wird die Version des Plug-Ins anhand der Metadaten festgelegt.

• Wahrscheinlich wird die neueste Version verwendet, wenn eine neue Version herauskommt. Wenn die Bewegung jedoch nicht behoben werden kann, wird der Build möglicherweise instabil.
• Daher ist normalerweise die Version des für jedes Projekt verwendeten Plug-Ins festgelegt.
• Im Fall von ↑ kann das Präfix nur angegeben werden, wenn groupId entweder org.apache.maven.plugin oder org.codehaus.mojo ist [^ 6]
• Wenn Sie ein anderes Plug-In von "groupId" als dieses verwenden möchten, indem Sie ein Präfix angeben, müssen Sie das Plug-In explizit festlegen.

[^ 6]: Genau genommen können Sie die "groupId" hinzufügen, nach der "" in "settings.xml" gesucht werden soll (Referenz: Einführung in die Auflösung von Plugin-Präfixen Guides / Einführung / Einführung in das Plugin-Präfix-Mapping.html # Configuring_Maven_to_Search_for_Plugins))

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.asciidoctor</groupId>
        <artifactId>asciidoctor-maven-plugin</artifactId>
        <version>1.5.8</version>
      </plugin>
    </plugins>
  </build>
</project>

• Einzelne Plugins werden mit dem Tag festgelegt --<plugin>ist unter<build> <plugins>aufgeführt
• Geben Sie den vollständig qualifizierten Namen des Plug-Ins mit "", "", "" an
• Hier wird Asciidoctor Maven Plugin gesetzt. --Diese Einstellung sperrt die Version von asciidoctor-mavne-plugin auf 1.5.8.

asciidoctor-maven-Plugin ausführen

> mvn asciidoctor:process-asciidoc
...
[INFO] BUILD SUCCESS
...

Auflösung der Präfixspezifikation (wenn Plug-In angegeben ist)

-Wenn das Plug-In wie in ↑ durch <Plugin> angegeben wird, ändert sich die Methode zum Auflösen des vollständig qualifizierten Namens aus der Präfixspezifikation geringfügig.

• Zuerst überprüft Maven die plugin.xml jedes Plugins, das explizit in pom.xml festgelegt ist.
• Normalerweise wird "plugin.xml" unter "META-INF / maven" im Plugin-Jar gespeichert.
• Zum Beispiel sieht die plugin.xml von asciidoctor-mavne-plugin folgendermaßen aus:

asciidoctor-maven-Plugin Plugin.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- Generated by maven-plugin-tools 3.5 on 2019-03-30 -->

<plugin>
  <name>Asciidoctor Maven Plugin and Doxia Parser</name>
  <description>Asciidoctor Maven Plugin and Doxia Parser (for Maven Site integration)</description>
  <groupId>org.asciidoctor</groupId>
  <artifactId>asciidoctor-maven-plugin</artifactId>
  <version>1.5.8</version>
  <goalPrefix>asciidoctor</goalPrefix>
  <isolatedRealm>false</isolatedRealm>
  <inheritedByDefault>true</inheritedByDefault>
  ...

• Das Wichtigste hier ist der in <goalPrefix> festgelegte Wert --Die Plugins groupId und artefaktId, deren Wert dem in der Befehlszeile angegebenen Präfix entspricht, werden übernommen.
• Schließlich wird "Version" wie folgt bestimmt
• Wenn in pom.xml angegeben, wird diese Version übernommen
• Wenn nicht angegeben, wird es aus den Metadaten (maven-metadata.xml) für jede Artefakt-ID bestimmt (dieselbe Methode wie wenn kein Plug-In angegeben ist).

Beziehung zwischen Artefakt-ID und Präfix

• In der bisherigen Erklärung können Sie sehen, dass arifactId und Präfix im Wesentlichen nichts miteinander zu tun haben.
• Das Präfix wird durch "<Präfix>" in "maven-metadata.xml" oder "" in "plugin.xml" bestimmt.
• Die tatsächlich vorhandenen Plug-Ins haben jedoch die folgende Beziehung zwischen "Artefakt-ID" und Präfix.
• Für offizielle Plugins des Maven-Projekts --Wenn artefaktId`` maven-XXX-plugin ist, ist XXX das Präfix
• Für andere Plug-Ins --Wenn artefaktId`` XXX-Maven-Plugin ist, ist XXX das Präfix ――Dies sind die Ergebnisse der Empfehlung solcher Namensregeln, und dies bedeutet nicht, dass Sie ohne diesen Namen kein Plug-In erstellen können.
• Wenn Sie es erstellen möchten, können Sie auch ein Plug-In mit "arifactId" erstellen, das sich von dieser Namensregel völlig unterscheidet.
• ** Der Name "maven-XXX-plugin" soll jedoch darauf hinweisen, dass es sich um das offizielle Plug-in von Maven handelt. Seien Sie also vorsichtig, da die nicht offizielle Verwendung dieses Namens zu einer Markenverletzung führt. ** - Important Notice: Plugin Naming Convention and Apache Maven Trademark
• Ungewöhnliche Benennungen sind nicht vorteilhaft, da sie nur Benutzer verwirren. Wenn Sie also Ihr eigenes Plug-In erstellen, können Sie "Artefakt-ID" sicher als "XXX-Maven-Plugin" verwenden, es sei denn, Sie haben einen bestimmten Grund.
• Also, Artefakt-ID und Präfix sind nicht im Wesentlichen verwandt, aber es ist in Ordnung zu glauben, dass sie in der Praxis verwandt sind (glaube ich).
• Also, wenn artefaktId`` foo-maven-plugin ist, können Sie sich das Präfix als foo vorstellen (glaube ich)
• Im Gegenteil, wenn das Präfix "foo" ist, können Sie denken, dass "artefaktId" "foo-maven-plugin" ist (wenn es sich nicht um ein vom Maven-Projekt bereitgestelltes Plugin handelt).

Plug-In-Einstellungen (Parameter)

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello World!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn antrun:run
...
main:
     [echo] Hello World!!
...

--Plug-In-Einstellungen (** Parameter **) können mit dem Tag unter beschrieben werden

• Die Tags, die unter "" angegeben werden können, sind für jedes Plug-In-Ziel unterschiedlich.
• Hier verwenden wir ein Plugin namens maven-antrun-plugin
• Dieses Plugin hat das Ziel ausführen
• Sie können sehen, dass auf der Zielbeschreibungsseite "Ausführen" die Parameter aufgelistet sind, die mit "" angegeben werden können.
• Für Plug-Ins mit mehreren Zielen werden die unter "" angegebenen Parameter auf alle Ziele angewendet.

Überprüfen Sie die Steckerbeschreibung

• Sie können auf der Erklärungsseite jedes Steckers überprüfen, welche Ziele jeder Stecker hat und welche Parameter angegeben werden können.
• Wenn Sie jedoch Probleme beim Öffnen jeder Seite haben, können Sie dies mit maven-help-plugin überprüfen.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn help:describe
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun

This plugin has 2 goals:

antrun:help
  Description: Display help information on maven-antrun-plugin.
    Call mvn antrun:help -Ddetail=true -Dgoal=<goal-name> to display parameter
    details.

antrun:run
  Description: Maven AntRun Mojo.
    This plugin provides the capability of calling Ant tasks from a POM by
    running the nested Ant tasks inside the <tasks/> parameter. It is
    encouraged to move the actual tasks to a separate build.xml file and call
    that file with an <ant/> task.

For more information, run 'mvn help:describe [...] -Ddetail'
...

• Durch Ausführen des Ziels beschreiben können Sie das durch "" angegebene Plugin beschreiben. Kann bestätigt werden
• "" und "" ermöglichen die Identifizierung des Plug-Ins als "Maven-Antrun-Plugin". -- beschreiben Wie Sie auf der Zielbeschreibungsseite sehen können, können Sie das Ziel mit <Ziel> eingrenzen und Details (Parameter, die für jedes Ziel angegeben werden können) mit <detail> ausgeben.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
          <goal>run</goal>
          <detail>true</detail>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn help:describe
...
antrun:run
  Description: Maven AntRun Mojo.
    ...
  Implementation: org.apache.maven.plugin.antrun.AntRunMojo
  Language: java

  Available parameters:

    ...

    target
      The XML for the Ant target. You can add anything you can add between
      <target> and </target> in a build.xml.

    ...
...

-Obwohl das Beispiel von ↑ weggelassen wird, werden alle Parameter mit Erläuterungen ausgegeben.

In den Systemeigenschaften angegeben

• Die in "" von "Hilfe: Beschreibung" angegebenen Parameter können auch in den Systemeigenschaften angegeben werden.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn help:describe -Dplugin=antrun
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun

This plugin has 2 goals:

antrun:help
  Description: Display help information on maven-antrun-plugin.
    ...

antrun:run
  Description: Maven AntRun Mojo.
    ...

For more information, run 'mvn help:describe [...] -Ddetail'
...

---Dplugin = antrun wird bei der Ausführung von Maven als Systemeigenschaft angegeben

• Eine Beschreibung des Parameters plugin finden Sie unter Dokumentation.
• Wie Sie sehen können, können Sie mit einigen Zielparametern Werte in Systemeigenschaften übergeben.
• Nicht alle Parameter können in den Systemeigenschaften angegeben werden
• Ob ein Parameter in einer Systemeigenschaft angegeben werden kann, kann überprüft werden, indem geprüft wird, ob das Dokument des Parameters ** Benutzereigenschaft ** enthält.
• In der Plugin-Parameterdokumentation steht beispielsweise "User Property: Plugin". Kann bestätigt werden
• Dies bedeutet, dass Sie einen Wert mit einer Eigenschaft namens "Plugin" angeben können.
• Der Parametername und der Eigenschaftsname stimmen nicht immer überein ** --plugin stimmt einfach überein, wie antrun skip Einige sind es nicht --Hier bedeutet ** Eigenschaften **, dass Sie nicht nur Systemeigenschaften, sondern auch in pom.xml angeben können.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <plugin>jdeps</plugin>
  </properties>

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-help-plugin</artifactId>
        <version>3.2.0</version>
      </plugin>
    </plugins>
  </build>
</project>

• In <Eigenschaften> wird jdeps im Plugin gesetzt.

Ausführungsergebnis (wenn das Plugin nicht in den Systemeigenschaften angegeben ist)

> mvn help:describe
...
Name: Apache Maven JDeps Plugin
Description: The JDeps Plugin uses the jdeps tool to analyze classes for
  internal API calls.
Group Id: org.apache.maven.plugins
Artifact Id: maven-jdeps-plugin
Version: 3.1.2
Goal Prefix: jdeps
...

Ausführungsergebnis (wenn Plugin in den Systemeigenschaften angegeben ist)

> mvn help:describe -Dplugin=antrun
...
Name: Apache Maven AntRun Plugin
Description: Runs Ant scripts embedded in the POM
Group Id: org.apache.maven.plugins
Artifact Id: maven-antrun-plugin
Version: 1.8
Goal Prefix: antrun
...

• Wenn keine Systemeigenschaften angegeben sind, wird der in <Eigenschaften> (jdeps) angegebene Wert übernommen.
• Wenn Sie eine Systemeigenschaft angeben, wird dieser Wert (antrun) übernommen.

Lebenszyklus und Phase

――Selbst wenn Sie kurz gesagt "bauen" sagen, umfasst der Inhalt verschiedene Prozesse.

• Um beispielsweise ein einfaches Java-Programm zu erstellen, kann die folgende Verarbeitung in Betracht gezogen werden.

1. Kompilieren Sie den Quellcode
2. Sammeln Sie Ressourcendateien
3. Kompilieren Sie den Testcode
4. Sammeln Sie Ressourcendateien zum Testen
5. Führen Sie den Testcode aus
6. Packen Sie die Kompilierungsergebnisse und Ressourcendateien in einem Archiv wie einem JAR zusammen.
7. Speichern Sie das Archiv an Ort und Stelle

• In Maven wird jeder dieser Prozesse als ** Phase ** bezeichnet. --Und die Menge der Phasen heißt ** Lebenszyklus **

Eingebauter Lebenszyklus

--Maven hat standardmäßig die folgenden drei Lebenszyklen. - default - clean - site

Standardlebenszyklus

• Der "Standard" -Lebenszyklus definiert den Lebenszyklus vom Erstellen eines Projekts bis zur Bereitstellung.
• Der "Standard" -Lebenszyklus besteht aus den folgenden Phasen:
  1. validate
  2. initialize
  3. generate-sources
  4. process-sources
  5. generate-resources
  6. process-resources
  7. compile
  8. process-classes
  9. generate-test-sources
  10. process-test-sources
  11. generate-test-resources
  12. process-test-resources
  13. test-compile
  14. process-test-classes
  15. test
  16. prepare-package
  17. package
  18. pre-integration-test
  19. integration-test
  20. post-integration-test
  21. verify
  22. install
  23. deploy

Lebenszyklus reinigen

--clean Lifecycle definiert einen Lebenszyklus, der Projektartefakte löscht --clean Der Lebenszyklus besteht aus folgenden Phasen 1. pre-clean 2. clean 3. post-clean

Standortlebenszyklus

--site Lifecycle definiert den Lebenszyklus der Generierung von Projektwebsites

• Der Lebenszyklus "Standort" besteht aus folgenden Phasen:
  1. pre-site
  2. site
  3. post-site
  4. site-deploy

Beziehung zwischen Phasen und Plug-In-Zielen

• Jede Lebenszyklusphase ist mit den Zielen des Plug-Ins verknüpft, das in dieser Phase ausgeführt wird.

sauber, Standort Für den Lebenszyklus

• Zum Beispiel sind im "sauberen" Lebenszyklus und im "Standort" -Lebenszyklus die Ziele wie folgt verknüpft:

** Plug-In reinigen **

** Site-Plug-In **

--Das heißt, wenn Sie die "Clean" -Phase ausführen, wird das "Clean" -Ziel des "Maven-Clean-Plugins" ausgeführt.

Für den Standardlebenszyklus

• Im Fall des "Standard" -Lebenszyklus ist die Zuordnung zwischen der Phase und dem Ziel nicht festgelegt.
• Die im "Standard" -Lebenszyklus ausgeführten Ziele hängen von der ** Verpackung ** des Projekts ab.

packaging -Packaging ist ein Einstellungswert, der bestimmt, wie das Projekt verpackt wird, und einer der folgenden Werte kann angegeben werden. - pom - jar - ejb - maven-plugin - war - ear - rar --Diese Verpackung ist in pom.xml wie folgt angegeben:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...
  <packaging>jar</packaging>
  ...
</project>

• Hier wird "Glas" als Verpackung angegeben.
• Das Tag kann in pom.xml weggelassen werden.
• Wenn nicht angegeben, ist die Standardeinstellung "jar"

Ziele für jede Verpackung

--default Die mit den Lebenszyklusphasen verbundenen Ziele unterscheiden sich je nach Verpackung wie folgt:

• Als Beispiel sind die mit "pom" und "jar" verbundenen Ziele wie folgt:
• Da die Anzahl der Phasen groß ist, werden Phasen ausgeschlossen, die mit nichts verbunden sind ("validieren" usw.).
• Informationen zu anderen Verpackungen finden Sie unter Maven Core - Plugin-Bindungen für die Referenz zum Standardlebenszyklus.

pom

jar

Führen Sie eine Phase durch

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Führen Sie die Testphase aus

> mvn test
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...

--Phase kann ausgeführt werden, indem es im Argument des Befehls mvn angegeben wird.

• Hier versuche ich, die "Test" -Phase für ein Projekt durchzuführen, dessen Verpackung "jar" ist. --packaing ist standardmäßig "jar", da die Beschreibung von "" weggelassen wird.
• Wenn Sie eine Phase angeben und ausführen, werden auch alle Phasen vor dieser Phase der Reihe nach ausgeführt.
• Zum Beispiel werden Phasen wie "Validieren", "Prozessressourcen" und "Testkompilieren" vor der "Test" -Phase definiert.
• Im obigen Beispiel sehen Sie, dass maven-resources-plugin: resources, maven-compiler-plugin: compile, ... ausgeführt werden. --Wenn eine Phase ausgeführt wird, werden alle mit dieser Phase verbundenen Ziele ausgeführt. -- Maven-Resources-Plugin: Resources Das Ziel ist in der Phase Resources, maven-compiler-plugin: compile Das Ziel ist an die Phase compile gebunden

Führen Sie dies aus, indem Sie mehrere Phasen und Ziele angeben

> mvn clean compiler:compile

--Mehr Phasen und Ziele können im Befehl mvn angegeben und ausgeführt werden.

• In diesem Fall lautet die Ausführungsreihenfolge clean → compiler: compile.
• Mit anderen Worten, es wird in der durch das Argument angegebenen Reihenfolge ausgeführt.

Verknüpfen Sie Ziele mit Phasen

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <target>
            <echo>Hello Antrun!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (default) @ hello ---
[INFO] Executing tasks

main:
     [echo] Hello Antrun!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...

• Jedes Ziel kann mit jeder Phase verknüpft werden
• Phase und Ziel sind in den Plug-In-Einstellungen mit "<Ausführung>" verknüpft.
• Geben Sie die Phase mit "" an und geben Sie das Ziel an, das mit " " verknüpft werden soll --Hier ist das "Run" -Ziel des "Maven-Antrun-Plugins" mit der "Validate" -Phase verbunden.
• Wie Sie der Struktur " " entnehmen können, können mehrere Ziele desselben Plug-Ins mit einer Phase verknüpft werden.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jdeps-plugin</artifactId>
        <version>3.2.6</version>
        <executions>
          <execution>
            <phase>verify</phase>
            <goals>
              <goal>jdkinternals</goal>
              <goal>test-jdkinternals</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn verify
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] --- maven-jdeps-plugin:3.1.2:jdkinternals (default) @ hello ---
...
[INFO] --- maven-jdeps-plugin:3.1.2:test-jdkinternals (default) @ hello ---

• Verknüpfung von "jdkinternals" und "test-jdkinternals" des "maven-jdeps-plugins" mit der "verify" -Phase
• Wenn mehrere Ziele mit einer Phase verknüpft sind, werden diese Ziele in der auf pom.xml [^ 7] angegebenen Reihenfolge ausgeführt.
• Mit anderen Worten, im Fall der Einstellung ↑ wird sie in der Reihenfolge jdkinternals → test-jdkinternals ausgeführt.
• Sie können die Ausführungsreihenfolge ändern, indem Sie die Reihenfolge der -Tags ändern.

Verknüpfung zu mehreren Phasen

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>foo</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
          <execution>
            <id>bar</id>
            <phase>compile</phase>
            <goals>
              <goal>run</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <target>
            <echo>Hello Antrun!!</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (foo) @ hello ---
...
     [echo] Hello Antrun!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-antrun-plugin:1.8:run (bar) @ hello ---
...
     [echo] Hello Antrun!!
...

• Wenn Sie mehrere "<Ausführung>" - Tags schreiben, können Sie Ziele mit mehreren Phasen verknüpfen.
• Wenn Sie mehr als eine <Ausführung> angeben, müssen Sie auch das Tag angeben.
• Setzen Sie "" auf einen eindeutigen Wert, der die "<Ausführung>" identifizieren kann --Dieser Wert wird zur Laufzeit an die Konsole ausgegeben ((foo) Teil von maven-antrun-plugin: 1.8: run (foo))
• Es ist nützlich für das Debuggen, wenn der Build nicht gut funktioniert, da es Informationen gibt, um zu identifizieren, welche <Ausführung> ausgeführt wurde. ―― Deshalb ist es besser, einen beschreibenden Namen anzugeben, der leicht zu identifizieren ist.

Für jede Ausführung festlegen

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>foo</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>VALIDATE!!</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>bar</id>
            <phase>compile</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>COMPILE!!</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn compile
...
[INFO] --- maven-antrun-plugin:1.8:run (foo) @ hello ---
...
     [echo] VALIDATE!!
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-antrun-plugin:1.8:run (bar) @ hello ---
...
     [echo] COMPILE!!
...

• Die , die die Zieleinstellung beschreibt, kann auch für jede <Ausführung> angegeben werden. ――Dies ermöglicht es, die Einstellungen für jede bestimmte Phase zu teilen.

Eine spezielle ID, die übernommen wird, wenn das Ziel direkt ausgeführt wird

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <target>
                <echo>Hello @ default-cli</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>validate-phase</id>
            <phase>validate</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <echo>Hello @ validate-phase</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn antrun:run
...
     [echo] Hello @ default-cli
...

> mvn validate
...
     [echo] Hello @ validate-phase
...

• Wenn Sie das Ziel direkt ausführen, ist "id" standardmäßig "default-cli"
• Wenn Sie daher "<Ausführung> " mit diesem Wert festlegen, können Sie die Einstellung beschreiben, die nur angewendet wird, wenn das Ziel direkt ausgeführt wird.

Ausführen durch Angabe der ID

• Seit 3.3.1 von Maven ist es möglich, das Ziel auszuführen, indem "" von "<Ausführung>" angegeben wird.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <target>
                <echo>Hello default-cli!!</echo>
              </target>
            </configuration>
          </execution>
          <execution>
            <id>foo</id>
            <configuration>
              <target>
                <echo>Hello Foo!!</echo>
              </target>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

• Die beiden "", "default-cli" und "foo" definieren "<Ausführung>".

Ausführungsergebnis

> mvn antrun:run
...
     [echo] Hello default-cli!!

> mvn antrun:run@foo
...
     [echo] Hello Foo!!

• Wenn Sie nur mit antrun: run ausführen, wird default-cli ausgeführt.
• Durch Befolgen der Zielspezifikation mit "@ ", wie in "antrun: run @ foo", wird die "<Ausführung>" der angegebenen "" ausgeführt.

Standardphase

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <version>3.1.1</version>
        <executions>
          <execution>
            <goals>
              <goal>check</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Ausführungsergebnis

> mvn verify
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] --- maven-checkstyle-plugin:3.1.1:check (default) @ hello ---

• Hinzufügen von maven-checkstyle-plugin, um die Phase "verify" auszuführen
• In pom.xml wird in "<Ausführung>" nur " Prüfung </ Ziel>" angegeben, nicht "".
• Wenn Sie sich jedoch das Ausführungsergebnis ansehen, können Sie sehen, dass das Ziel "Prüfen" in der Phase "Verifizieren" ausgeführt wird. --Ziele können standardmäßig die ihnen zugeordneten Phasen definieren.
• Wenn Sie sich die Seite [Zielbeschreibung überprüfen] ansehen (https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html), sehen Sie, dass die Standardphase "Verifizieren" ist. Verstehen --Wenn die Phase nicht in "<Ausführung>" angegeben ist, wird sie in der dieser Standardeinstellung zugeordneten Phase ausgeführt.
• Wenn einem Ziel keine Phasen zugeordnet sind, kann dieses Ziel nur aktiviert werden, wenn es direkt in der Befehlszeile angegeben wird.

Angabe der Steckerversion

• Das Plug-In kann in gewissem Umfang verwendet werden, ohne es explizit mit "" festzulegen -Einige grundlegende Plugins (wie das Maven-Compiler-Plugin) werden abhängig von den Verpackungseinstellungen automatisch angewendet
• Wenn ein Präfix angegeben wird, werden "groupId", "artefaktId" und "version" automatisch aufgelöst.
• Wenn es ohne Einstellungen funktioniert, müssen Sie nicht "" schreiben.
• Die Ausführungsmethode ohne Einstellung von kann jedoch bei jeder Ausführung die Version des Plug-Ins ändern.
• Zum Beispiel kann sich das Plug-In, das automatisch durch die Verpackung festgelegt wird, je nach Version von Maven ändern.
• Zum Beispiel können Sie die Version des in 3.6.3 eingestellten Plug-Ins unter [hier] überprüfen (https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging).
• Wenn Sie nicht dieselbe Version von Maven haben, die Ihre Entwickler verwenden, können die Build-Ergebnisse von Entwickler zu Entwickler variieren.
• (Erstens ist die standardmäßig eingestellte Version des Plug-Ins alt)
• Außerdem ist die Version des Plug-Ins, die durch Angabe des Präfixes aufgelöst wird, im Grunde die neueste im Repository. —— Wenn sich die letzte Laufzeit ändert, können sich die Ergebnisse ändern. ―― Daher ist es grundsätzlich sinnvoll, die zu verwendende Version des Plug-Ins anzugeben, auch wenn Sie der Meinung sind, dass dies problematisch ist.
• Im hier beschriebenen pom.xml-Beispiel werden die Plug-In-Einstellungen jedoch aus folgenden Gründen möglicherweise weggelassen. ――Wenn die Anzahl der Beschreibungen zunimmt, fühle ich mich unwohl beim Lesen.
• Ich kann nicht auf den notwendigen Teil achten (den Teil, den ich zu erklären versuche)

Eltern-Kind-Beziehung des Projekts

――Sie können im Projekt eine Eltern-Kind-Beziehung haben

Ordnerstruktur

|-pom.xml
`-child/
  `-pom.xml

• Legen Sie das übergeordnete Projekt pom.xml in den obersten Ordner und das untergeordnete Projekt pom.xml in den Ordner "child"

/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>artifactId = ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Im übergeordneten Projekt pom.xml müssen Sie "pom" für "" angeben

/child/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>
</project>

• Verwenden Sie im untergeordneten Projekt pomx.ml "", um das übergeordnete Projekt anzugeben --<parent>gibt groupId, artefaktId, version an, um das übergeordnete POM zu identifizieren
• In einem Eltern-Kind-Beziehungsprojekt erbt das untergeordnete POM das übergeordnete POM.
• Aus diesem Grund werden Einstellungen, die nicht in der untergeordneten Datei pom.xml beschrieben sind, von den Einstellungen in der übergeordneten Datei pom.xml übernommen.
• Da die übergeordneten Einstellungen für "" und "" vererbt werden, ist die Beschreibung in der untergeordneten pom.xml nicht erforderlich.
• Es muss jedoch "" wie erwartet angegeben werden.

Ausführungsergebnis (oberster Ordner)

> mvn antrun:run
...
     [echo] artifactId = parent

Ausführungsergebnis (untergeordneter Ordner)

> mvn antrun:run
...
     [echo] artifactId = child

• Da die Einstellung von ebenfalls vererbt wird, kann das im übergeordneten Projekt festgelegte Plug-In "antrun" auch im untergeordneten Projekt verwendet werden.

So lösen Sie das übergeordnete Projekt

--Parent pom.xml mit <parent> wird in der folgenden Reihenfolge durchsucht:

1. Wenn "" angegeben ist, verweisen Sie an dieser Stelle auf pom.xml
2. Wenn <relativePath> nicht angegeben ist, verweisen Sie auf pom.xml von ** eine Ebene höher **
3. Wenn nicht, durchsuchen und durchsuchen Sie das Repository (lokal oder remote).

• Im Beispiel von ↑ befand sich das übergeordnete Projekt über dem untergeordneten Projekt, sodass das übergeordnete POM ohne Angabe des Speicherorts gefunden wurde.

Geben Sie den Speicherort des übergeordneten Projekts an

• Bei einer Ordnerstruktur wie ↓ muss der Pfad jedoch mit "" angegeben werden.

Ordnerstruktur

|-parent/
| `-pom.xml
`-child/
  `-pom.xml

--parent und child stehen nebeneinander, und pom.xml des übergeordneten Projekts existiert nicht über dem untergeordneten Projekt.

• Wenn Sie Maven in einem untergeordneten Projekt in diesem Status ausführen, wird die folgende Fehlermeldung angezeigt:

Ausführungsergebnis (untergeordnetes Projekt)

> mvn antrun:run
...
[FATAL] Non-resolvable parent POM for example:child:1.0.0: Failure to find example:parent:pom:1.0.0 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ line 6, column 11
 @
...

• Um dies zu lösen, müssen Sie die JAR des übergeordneten Projekts im Repository registrieren oder den Speicherort des übergeordneten Projekts mit "" angeben, wie unten gezeigt.

/child/pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
    <relativePath>../parent/pom.xml</relativePath>
  </parent>

  <artifactId>child</artifactId>
</project>

Ausführungsergebnis (untergeordnetes Projekt)

> mvn antrun:run
...
     [echo] artifactId = child

• Das übergeordnete Projekt wurde gefunden und bearbeitet

POM-Zusammenführung

• Wenn der POM eine Eltern-Kind-Beziehung hat, wird der übergeordnete POM mit dem untergeordneten POM zusammengeführt.
• Mal sehen, wie die Zusammenführung durchgeführt wird

Eltern pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <properties>
    <hoge>PARENT</hoge>
    <fuga>PARENT</fuga>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>

  <build>
    <resources>
      <resource>
        <directory>parent/dir</directory>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>hoge = ${hoge}</echo>
            <echo>fuga = ${fuga}</echo>
            <echo>piyo = ${piyo}</echo>
            <echo>dependencies[0].artifactId = ${project.dependencies[0].artifactId}</echo>
            <echo>dependencies[1].artifactId = ${project.dependencies[1].artifactId}</echo>
            <echo>resources[0].directory = ${project.build.resources[0].directory}</echo>
            <echo>resources[1].directory = ${project.build.resources[1].directory}</echo>
            <echo>plugins[0] = ${project.build.plugins[0].id}</echo>
            <echo>plugins[1] = ${project.build.plugins[1].id}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Zur Überprüfung werden einige Einstellungen beschrieben, damit die Einstellungen mit dem Plug-In "antrun" angezeigt werden können.

Kind pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>

  <properties>
    <fuga>CHILD</fuga>
    <piyo>CHILD</piyo>
  </properties>

  <dependencies>
    <dependency>
      <groupId>commons-codec</groupId>
      <artifactId>commons-codec</artifactId>
      <version>1.14</version>
    </dependency>
  </dependencies>

  <build>
    <resources>
      <resource>
        <directory>child/dir</directory>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jdeps-plugin</artifactId>
        <version>3.1.2</version>
      </plugin>
    </plugins>
  </build>
</project>

• Es erbt das übergeordnete POM und beschreibt, dass sich einige Einstellungen überschneiden.

Ausführungsergebnis (übergeordnetes Projekt)

> mvn antrun:run
...
     [echo] hoge = PARENT
     [echo] fuga = PARENT
     [echo] piyo = ${piyo}
     [echo] dependencies[0].artifactId = commons-lang3
     [echo] dependencies[1].artifactId = ${project.dependencies[1].artifactId}
     [echo] resources[0].directory = parent/dir
     [echo] resources[1].directory = ${project.build.resources[1].directory}
     [echo] plugins[0] = org.apache.maven.plugins:maven-antrun-plugin:1.8
     [echo] plugins[1] = ${project.build.plugins[1].id}

• Versuchen Sie zunächst, jeden Einstellungswert im übergeordneten Projekt auszugeben
• Natürlich wird nur der im übergeordneten POM festgelegte Wert ausgegeben, und der nicht festgelegte Wert wird so ausgegeben, wie er ist, ohne dass der Ausdruck ausgewertet wird.

Ausführungsergebnis (untergeordnetes Projekt)

> mvn antrun:run
...
     [echo] hoge = PARENT
     [echo] fuga = CHILD
     [echo] piyo = CHILD
     [echo] dependencies[0].artifactId = commons-codec
     [echo] dependencies[1].artifactId = commons-lang3
     [echo] resources[0].directory = child/dir
     [echo] resources[1].directory = ${project.build.resources[1].directory}
     [echo] plugins[0] = org.apache.maven.plugins:maven-antrun-plugin:1.8
     [echo] plugins[1] = org.apache.maven.plugins:maven-jdeps-plugin:3.1.2

• Aufgrund der Ausgabe im untergeordneten Projekt wird die untergeordnete POM-Einstellung für den überlappenden Teil (` > usw.) in der Einzelwerteinstellung übernommen.
• Andererseits basiert der überlappende Teil (<Abhängigkeiten>, <Plugins> usw.) bei der Einstellung mehrerer Werte auf dem übergeordneten POM und das Element des untergeordneten POM wird hinzugefügt.
• Grundsätzlich werden einwertige Elemente überschrieben, und bei mehrwertigen Elementen (z. B. "") werden Elemente hinzugefügt.
• Es gibt jedoch einige Ausnahmen, z. B. " " ist ein mehrwertiges Element, das jedoch überschrieben wird.
• Offizielle Dokumentation besagt, dass "" ebenfalls zusammengeführt werden muss Überschrieben
• In Bezug auf die Implementierung ModelMerger Es scheint, dass POM in einer Klasse namens .java zusammengeführt wird.
• [MergeBuildBase_Resources ()] dieser Klasse (https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/java/org/apache/maven/model/merge/ ModelMerger.java # L2195) führt "" zusammen
• In dieser Implementierung soll "" zusätzlich zusammengeführt werden
• Aber in Wirklichkeit ist es eine Unterklasse dieses ModelMerger MavenModelMerger org / apache / maven / model / merge / MavenModelMerger.java) scheint zu verschmelzen --MavenModelMerger ist [mergeBuildBase_Resources ()](https://github.com/apache/maven/blob/maven-3.6.3/maven-model-builder/src/main/java/org/apache/maven/model Überschreiben von /merge/MavenModelMerger.java#L381), um den Inhalt des übergeordneten POM nur dann zusammenzuführen, wenn "" des "Ziels" (untergeordnetes POM) leer ist.
• Mit anderen Worten, wenn im untergeordneten POM "" vorhanden ist, wird die Zusammenführung nicht durchgeführt und nur der Inhalt des untergeordneten POM wird übernommen (was zu einer Überschreibungsoperation führt).
• Müssen Sie sich außer "" diese "MavenModelMerger" -Implementierung ansehen?

Überprüfen Sie den POM nach dem Zusammenführen

--POMs haben eine Eltern-Kind-Beziehung. Wenn Sie mehrere POMs als Eltern haben, können Sie den endgültigen Status nicht einfach anhand der Terminal-POMs ermitteln.

• Insbesondere wenn der Build nicht funktioniert, möchten Sie häufig sicherstellen, dass die POMs wie erwartet zusammengeführt werden.
• In solchen Fällen kann das Ziel effektiv-pom des maven-help-plugin verwendet werden.

effective-Führen Sie das Pom-Ziel aus

> mvn help:effective-pom
...
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>
  <groupId>example</groupId>
  <artifactId>child</artifactId>
  <version>1.0.0</version>
(Weggelassen, weil es lang ist)
...

--effective-pom Goal druckt das endgültige POM mit den Informationen aller übergeordneten POMs einschließlich des zusammengeführten Super-POMs. ――Wenn Sie dies betrachten, können Sie sehen, wie die Einstellungen dieses Projekts tatsächlich sind.

Konfigurationen zusammenführen

• Beschreibung der Plug-In-Einstellungen <Konfigurationen> Im Folgenden ist keine feste Schemadefinition festgelegt, da die Einstellungen für jedes Plug-In unterschiedlich sind.
• Daher erfolgt das Zusammenführen von "" nach bestimmten Regeln einheitlich.
• Wenn zum Beispiel "<Ausführung>", ist die Definition so festgelegt, dass sie durch "" identifiziert werden kann, sodass Sie dieselbe "" zusammenführen können. ――Die Tags unter "" können jedoch nicht auf diese Weise identifiziert werden. Es scheint also, als würden Tags an derselben Position zusammengeführt.
• (Ich habe die genauen Spezifikationen und die Implementierung nicht bestätigt, daher fühle ich mich so) ――Lass uns sehen, wie es mit einem tatsächlichen Beispiel zusammengeführt wird

Übergeordnetes POM

      ...
        <configuration>
          <persons>
            <person>
              <name>Taro</name>
              <age>18</age>
            </person>
            <person>
              <name>Hanako</name>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

Kind POM

      ...
        <configuration>
          <persons>
            <person>
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person>
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

Überprüfen Sie in diesem Zustand das Zusammenführungsergebnis mit "help: effektive-pom".

effective-pom

      ...
        <configuration>
          <persons>
            <person>
              <sex>male</sex>
              <name>Taro</name>
              <age>18</age>
            </person>
            <cat>nya-</cat>
            <person>
              <name>Ayako</name>
              <age>15</age>
              <sex>female</sex>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

――Es ist schwer in Worten zu erklären, aber Sie können sehen, dass sie auf nette Weise zusammengeführt werden. ――Wenn sich ein Tag mit demselben Namen an derselben Position befindet, wird der Inhalt wahrscheinlich rekursiv zusammengeführt.

Steuern Sie, wie zusammengeführt werden soll

――Ich bin der Meinung, dass selbst das Standardverhalten einigermaßen gut zusammengeführt werden kann. --Aber wenn dies ein Problem ist, können Sie das Standard-Zusammenführungsverhalten ändern.

Übergeordnetes POM

      ...
        <configuration>
          <persons>
            <person>
              <name>Taro</name>
              <age>18</age>
            </person>
            <person>
              <name>Hanako</name>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

--Parent POM hat sich nicht geändert

Kind POM

      ...
        <configuration>
          <persons>
            <person combine.self="override">
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person combine.children="append">
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

• Hinzufügen der Attribute combile.self =" override " und comb.children =" append "

effective-pom

      ...
        <configuration>
          <persons>
            <person combine.self="override">
              <sex>male</sex>
            </person>
            <cat>nya-</cat>
            <person combine.children="append">
              <name>Hanako</name>
              <sex>female</sex>
              <name>Ayako</name>
              <age>15</age>
            </person>
            <person>
              <name>Rin</name>
              <age>12</age>
              <sex>female</sex>
            </person>
          </persons>
        </configuration>
      ...

• Sie können sehen, dass sich die Art der Zusammenführung nur für das Element geändert hat, zu dem das Attribut "kombinieren" hinzugefügt wurde.
• Wenn Sie "comb.self =" override "" angeben, werden die Elemente des übergeordneten POM vollständig verworfen und nur die Elemente des untergeordneten POM verwendet.
• Wenn comb.children =" append " angegeben ist, wird das untergeordnete POM-Element einfach am Ende des übergeordneten POM-Elements hinzugefügt.
• Durch die Verwendung dieser beiden Attribute im untergeordneten POM können Sie die Zusammenführungsmethode in gewissem Maße anpassen.
• Diese Attribute sind jedoch nur für das Element wirksam, das dieses Attribut beschreibt.
• Wird nicht an verschachtelte Elemente weitergegeben
• Wenn Sie das Verhalten verschachtelter Elemente ändern möchten, müssen Sie das Attribut combin. * Für verschachtelte Elemente auf die gleiche Weise angeben.

Fügen Sie nur die Definitionen im übergeordneten Projekt zusammen

• Elternprojekteinstellungen werden immer von untergeordneten Projekten geerbt
• Es ist praktisch, wenn die Einstellungen allen untergeordneten Projekten gemeinsam sind. Wenn die Einstellungen jedoch nur für einige untergeordnete Projekte erforderlich sind, erfolgt eine zusätzliche Vererbung.
• Daher gibt es eine Methode, um nur die Definition in das übergeordnete Projekt einzufügen und explizit in das untergeordnete Projekt anzuwenden, das die Definition verwenden möchte.

Fassen Sie die Definition des Plug-Ins zusammen

Eltern pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.8</version>
          <executions>
            <execution>
              <phase>validate</phase>
              <goals><goal>run</goal></goals>
              <configuration>
                <target>
                  <echo>Hello ${project.artifactId}</echo>
                </target>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

--Verwenden Sie , um Plugin-Definitionen im übergeordneten Projekt zusammenzustellen

• Darunter können Sie "" wie eine normale Plug-In-Definition schreiben.
• Was hier beschrieben wird, definiert jedoch nur die Einstellungen und wird nicht auf das Projekt angewendet.

Kind 1 Pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child1</artifactId>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
      </plugin>
    </plugins>
  </build>
</project>

• Um sich tatsächlich auf ein Projekt zu bewerben, beschreiben Sie "", "" in der Plug-In-Definition des Projekts, das Sie anwenden möchten. --Wenn die Version weggelassen wird, wird die unter beschriebene Version verwendet.
• Es ist auch möglich, individuelle Einstellungen im untergeordneten Projekt hinzuzufügen

Kind 2 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child2</artifactId>
</project>

――Dies verwendet kein Plug-In

Ausführungsergebnis (Kind 1)

> mvn validate
...
[INFO] ---------------------------< example:child1 >---------------------------
[INFO] Building child1 1.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-antrun-plugin:1.8:run (default) @ child1 ---
[INFO] Executing tasks

main:
     [echo] Hello child1
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

• Das Plug-In wird mit den im übergeordneten POM definierten Einstellungen angewendet.

Ausführungsergebnis (Kind 2)

> mvn validate
...
[INFO] ---------------------------< example:child2 >---------------------------
[INFO] Building child2 1.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

• Kein Plug-In angewendet

Fassen Sie Abhängigkeitsdefinitionen zusammen

Eltern pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.6</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
    </dependency>
  </dependencies>
</project>

--Verwenden Sie , um Abhängigkeitsdefinitionen in einem übergeordneten Element zu gruppieren

• Darunter können Sie das gleiche schreiben wie normale "<Abhängigkeiten>"
• Ähnlich wie bei ist die Definition hier nur eine Deklaration und wird individuell auf das Projekt angewendet.

Kind 1 Pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child1</artifactId>

  <dependencies>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
    </dependency>
  </dependencies>
</project>

• Wenden Sie in untergeordneten Projekten an, indem Sie "" und "" in die Abhängigkeit schreiben. --Wenn "" weggelassen wird, wird die von "" angegebene verwendet.
• Es ist auch möglich, "" unabhängig im untergeordneten Projekt zu überschreiben.

Kind 2 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child2</artifactId>
</project>

--Dies definiert keine Abhängigkeiten

Ausführungsergebnis (wirksam von Kind 1-pom）

> mvn help:effective-pom
...
  <dependencies>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>2.6</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
...

--commons-io wird in der im übergeordneten POM festgelegten Version angewendet

Ausführungsergebnis (gültig ab Kind 2)-pom）

> mvn help:effective-pom
...
  <dependencies>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.9</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>
...

• Die commons-io-Abhängigkeit wird nicht angewendet

Aggregation von Projekten

• Die Eltern-Kind-Beziehung war eine Form, in der sich das Kind auf den Elternteil bezog ――Daher bezieht sich der Elternteil bei der Projektaggregation auf das Kind. ――Wenn Sie Projekte aggregieren, können Sie Ziele und Phasen im übergeordneten Projekt angeben und ausführen.

Ordnerstruktur

|-pom.xml
`-sub/
  `-pom.xml

• Projekte, deren oberster Ordner die Aggregationsquelle ist
• Es gibt ein Projekt, das unter dem Ordner "child" zusammengefasst werden soll

Aggregationsquelle pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>root</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <modules>
    <module>sub</module>
  </modules>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Um Projekte zu aggregieren, verwenden Sie "" in dem Projekt, aus dem sie aggregiert werden. --Listen Sie unter die Projekte auf, die mit aggregiert werden sollen --Das des zu aggregierenden Projekts muss "pom" sein.

Pom aggregiert werden.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>sub</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--Schreiben Sie pom.xml, um es normal zu aggregieren

• Da dieses POM das Projekt der Aggregationsquelle nicht erbt, ist die Beschreibung von usw. individuell.

Ausführungsergebnis (im Aggregationsquellprojekt ausgeführt)

> mvn antrun:run
...
main:
     [echo] Hello sub
...
main:
     [echo] Hello root
...

• Wenn Sie das Ziel des Plug-Ins im Quellprojekt ausführen, wird dasselbe Ziel im Zielprojekt ausgeführt. ――Wenn Sie Projekte auf diese Weise aggregieren, werden die im Quellprojekt ausgeführten Befehle auch im Zielprojekt ausgeführt. ――Es ist praktisch, diesen Mechanismus zu haben, wenn Sie alle Projekte gleichzeitig erstellen möchten.

Aggregation und Eltern-Kind-Beziehungen kombinieren

• Aggregations- und Eltern-Kind-Beziehungsmechanismen können kombiniert werden (oder vielmehr normalerweise in Kombination verwendet werden)

Ordnerstruktur

|-pom.xml
`-child/
  `-pom.xml

Eltern pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <modules>
    <module>child</module>
  </modules>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>Hello ${project.artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Die Zusammensetzung des übergeordneten POM ändert sich nicht besonders

Kind pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.0</version>
  </parent>

  <artifactId>child</artifactId>
</project>

• Deklarieren Sie das übergeordnete Projekt mit ""
• Dadurch können die Plug-In-Einstellungen die übergeordneten Einstellungen erben, sodass keine Beschreibung erforderlich ist.

Ausführungsergebnis (im übergeordneten Projekt ausgeführt)

> mvn antrun:run
...
main:
     [echo] Hello parent
...
main:
     [echo] Hello child
...

• Eltern-Kind-Beziehung und Aggregation können gleichzeitig angewendet werden

Java-Projekt erstellen

• Verstehen Sie, wie ein Projekt mit "jar" -Verpackung erstellt wird.

Standardziele, die im Lebenszyklus ausgeführt werden

• Wenn Sie ein Projekt erstellen, das Java normal erstellt, wird beim Packen standardmäßig "jar" verwendet
• Daher sind die im "Standard" -Lebenszyklus ausgeführten Ziele:
  1. resources:resources
  2. compiler:compile
  3. resources:testResources
  4. compiler:testCompile
  5. surefire:test
  6. jar:jar
  7. install:install
  8. deploy:deploy ―― Sehen Sie sich nacheinander an, was jedes Ziel tut

Ressourcen sammeln

--Das erste, was ausgeführt wird, ist das [Ressourcenziel] des maven-resources-plugin (https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

--Überprüfen Sie mit der Mindestkonfiguration pom.xml

Ordnerstruktur

|-pom.xml
`-src/main/
  |-java/
  | `example/
  |  `-App.java
  `-resources/
    |-hoge.txt
    `-foo/
      `-bar.txt

--Dateien und Ordner sind entsprechend unter "src / main / resources" angeordnet

Befehlsausführung

> mvn resources:resources
...
[INFO] --- maven-resources-plugin:2.6:resources (default-cli) @ hello ---
...
[INFO] BUILD SUCCESS

--Ressourcen: Ressourcen Ziele direkt ausführen

Ordnerstruktur nach der Ausführung

|-pom.xml
|-src/main/
| |-java/
| | `example/
| |  `-App.java
| `-resources/
|   |-hoge.txt
|   `-foo/
|     `-bar.txt
`-target/classes/
  |-hoge.txt
  `-foo/
    `-bar.txt

• Der folgende Inhalt von "src / main / resources" wird in den Ordner "target / classes" kopiert. --maven-resources-plugin ermöglicht das Kopieren des Ressourcenordners des Projekts in den Ausgabeordner.
• Der Ressourcenordner und der Ausgabeordner lauten standardmäßig wie folgt.
• Ressourcenordner: src / main / resources
• Ausgabeordner: Ziel / Klassen
• Der Ressourcenordner ist der Ordner, der in "$ {project.build.resources}" festgelegt ist --Dieser Wert wird in Super POM auf "$ {project.basedir} / src / main / resources" gesetzt
• Der Ausgabezielordner ist der Speicherort, der durch den Parameter "outputDirectory" des Ziels "resources" angegeben wird. --Dieser Parameter ist standardmäßig "$ {project.build.outputDirectory}" --Und dieser Wert wird standardmäßig von Super POM auf $ {project.build.directory} / classes gesetzt
• Außerdem wird "$ {project.basedir} / target" in "$ {project.build.directory}" festgelegt --So können Sie das Verhalten anpassen, indem Sie pom.xml schreiben, zum Beispiel:

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <resources>
      <resource>
        <directory>src/main/hoge</directory>
      </resource>
    </resources>
  </build>
</project>

• Ändern des Ressourcenordners in "src / main / hoge"

Ordnerstruktur

|-pom.xml
`-src/main/
  |-hoge/
  | |-fizz.txt
  | `-hoge/
  |   `-fuga.txt
  |
  `-resources/
    |-buzz.txt
    `-foo/
      `-bar.txt

• Es gibt zwei Optionen: "src / main / resources" und "src / main / hoge".

Ressourcenziel ausführen

> mvn resources:resources
...

Ausführungsergebnis

|-pom.xml
|-src/main/
| |-hoge/
| | |-fizz.txt
| | `-hoge/
| |   `-fuga.txt
| |
| `-resources/
|   |-buzz.txt
|   `-foo/
|     `-bar.txt
|
`-target/classes/
  |-fizz.txt
  `-hoge/
    `-fuga.txt

--src / main / hoge Es wurde geändert, sodass nur das Folgende kopiert wird

• Zusammenfassend funktioniert das Ziel "Ressourcen: Ressourcen" standardmäßig wie folgt: --Kopieren Sie die Dateien und Ordner unter "$ {project.basedir} / src / main / resources" unter "$ {project.basedir} / target / classes"
• Ressourcenordner können mit " " festgelegt werden
• Der Ausgabezielordner kann mit " " festgelegt werden

Kompilieren Sie die Java-Quelle

• Das nächste auszuführende Ziel ist compile von maven-compiler-plugin. /plugins/maven-compiler-plugin/compile-mojo.html) Ziel

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

--Überprüfen Sie mit der Mindestkonfiguration POM

Ordnerstruktur

|-pom.xml
`-src/main/java
  `-example/
    `-Hello.java

• Einfache Konfiguration mit nur Hello.java

Kompilierungsziel ausführen

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-cli) @ hello ---
...
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]Quelloption 5 wird derzeit nicht unterstützt. Bitte verwenden Sie 6 oder höher.
[ERROR]Zieloption 1.5 wird derzeit nicht unterstützt. 1.Bitte verwenden Sie 6 oder höher.

• Fehler aufgrund eines Fehlers --Kompilierungsoption [-source](https://docs.oracle.com/javase/jp/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-B4EE2436-E146- 428D-A3CB-E0DAE27BA5B7) und [-target](https://docs.oracle.com/javase/jp/11/tools/javac.html#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-89CBEA- Der Fehlerinhalt besteht darin, dass die in 4EA0-AB7D-B418FA2C3DE9) angegebene Version mit "5", "1,5" zu alt ist.
• In JDK 11 sind die Versionen unter 5 für "-source" und "-target" können nicht angegeben werden JSMIG-GUID-77874D97-46F3-4DB5-85E4-2ACB5F8D760B)
• Wenn die Verpackung "jar" ist, ist die Standardversion des "maven-compiler-plugin" [3.1](https://maven.apache.org/ref/3.6.3/maven- core / default-bindings.html # Plugin_bindings_for_jar_packaging)
• In 3.1 von maven-compiler-plugin ist die Versionsspezifikation von -source und -target standardmäßig [1.5](https://github.com/apache/maven-compiler- Plugin / Blob / Maven-Compiler-Plugin-3.1 /src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L120)
• Übrigens in 3.8.1 des neuesten maven-compiler-plugins zum Zeitpunkt der Bestätigung [1.6](https://github.com/apache/maven-compiler-plugin/blob/maven-compiler-plugin-3.8. 1 / src / main / java / org / apache / maven / plugin / compiler / AbstractCompilerMojo.java # L100) ist die Standardeinstellung
• Um diesen Fehler zu beseitigen, müssen Sie die Version von "Maven-Compiler-Plugin" oder die Spezifikation von "Quelle" und "Ziel" erhöhen.
• Es ist sicher, beide anzugeben, um den Vorgang zu bestätigen.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Um source mit maven-compiler-plugin anzugeben, verwenden Sie source parameter. einstellen
• Obwohl es mit "" angegeben werden kann, kann es auch mit der Eigenschaft "maven.compiler.source" angegeben werden.
• Hier wird die Einstellung verwendet, die die Eigenschaft verwendet (Ist dies häufiger?)
• Gleiches gilt für target, das mit der Eigenschaft maven.compiler.target festgelegt werden kann.

Ausführungsergebnis

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-cli) @ hello ---
...
[WARNING] File encoding has not been set, using platform encoding MS932, i.e. build is platform dependent!
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
...

• Ich konnte kompilieren, bekam aber eine Warnung
• Die Warnung lautet, dass die Codierung der Quelldatei von den Standardeinstellungen der Umgebung abhängt.
• Geben Sie die Codierung der Quelldatei in [Codierungsparameter] an (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#encoding).
• Wie in der Beschreibung beschrieben, wird standardmäßig "$ {project.build.sourceEncoding}" verwendet
• Dieser Wert wird jedoch nicht in Super POM festgelegt, sodass ein Umgebungsstandard entsteht (z. B. MS932 für Windows).
• Also, lassen Sie uns auch die Codierung einstellen

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Aus der Beschreibung "$ {project.build.sourceEncoding}" könnte man denken, dass Sie das Element "" unter " " beschreiben sollten, aber in Wirklichkeit deklarieren Sie die Eigenschaft ( Wer weiß </ del>)
• Übrigens ist es möglich, es mit der Eigenschaft "encoding" festzulegen, aber wenn Sie es im Netz nachschlagen, wird die Methode "project.build.sourceEncoding" abgefangen. ――Wenn es sich um "Codierung" handelt, kann es auf andere Codierungen als die Java-Quelle angewendet werden, oder gibt es so etwas? (geeignet)

Ausführungsergebnis

> mvn compiler:compile
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-cli) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

• Ohne Vorwarnung erfolgreich kompiliert

Ausgabeergebnis

|-pom.xml
|-src/main/java/
| :
`-target/
  |-classes/
  : `-example/
      `-Hello.class

• Das Kompilierungsergebnis wird unter "Ziel / Klassen" ausgegeben
• Die Ausgabezieleinstellung wird im Dokument Ziel kompilieren nicht beschrieben.
• Dies ist die Implementierungsklasse für das Kompilierungsziel outputDirectory /org/apache/maven/plugin/compiler/CompilerMojo.java#L76) Im Feld deklariert
• Der Standardwert ist "$ {project.build.outputDirectory}"
• Da readonly = true gesetzt ist, kann dieses Feld nicht direkt von außen gesetzt werden.
• Der Quellordner ist standardmäßig "src / main / java" --Auch das Dokument enthält keine Beschreibung
• In Bezug auf die Implementierung compileSourceRoots /compiler/CompilerMojo.java#L70) im Feld deklariert
• Wenn Sie sich defaultValue ansehen, können Sie sehen, dass $ {project.compileSourceRoots} gesetzt ist. --Aber wenn ich versuche, auf diese Eigenschaft namens "project.compileSourceRoots" in pom.xml zu verweisen, kann ich den Wert nicht sehen. --compileSourceRoots ist MavenProject # L131) Als Klassenfeld deklariert
• Dieses Feld ist DefaultProjectBuilder Der Wert wird durch # L691 eingestellt.
• Aus dieser Implementierung können Sie ersehen, dass "project.build.sourceDirectory" auf "compileSourceRoots" gesetzt ist. --Und $ {project.basedir} / src / main / java wird in project.build.sourceDirectory von Super POM festgelegt. ――Wenn Sie sich diesen Mechanismus ansehen, können Sie davon ausgehen, dass Sie nicht mehrere Quellordner festlegen können.
• Wenn Sie mehrere Quellordner festlegen möchten, müssen Sie ein Plugin namens [build-helper-maven-plugin] installieren (https://www.mojohaus.org/build-helper-maven-plugin/).

• Zusammenfassend macht compiler: compile Folgendes: --Kompilieren Sie den Java-Quellcode unter "$ {project.basedir} / src / main / java" und geben Sie ihn in "$ {project.basedir} / target / classes" aus Die Optionen "-source" und "-target" von --javac können mit den Eigenschaften "maven.compiler.source" und "maven.compiler.target" angegeben werden
• Die Codierung kann mit der Eigenschaft project.build.sourceEncoding angegeben werden.
• Der Quellordner kann mit " " angegeben werden
• Wenn Sie mehrere Ordner angeben möchten, benötigen Sie das Build-Helper-Maven-Plugin
• Der Ausgabezielordner ist " "

Sammeln und Kompilieren von Ressourcen zum Testen

• Als Nächstes wird resources: testResources ausgeführt, das Testressourcen sammelt. Werden Sie compiler: testCompile, um den Quellcode zum Testen zu kompilieren
• Die Grundoperation von jedem ist die gleiche wie "Ressourcen: Ressourcen", "Compiler: Kompilieren", also nur grob

Ordnerstruktur

|-pom.xml
`-src/test/
  |-java/
  | `-example/
  |   `-HelloTest.java
  |
  `-resources/
    |-foo/
    | `-bar.txt
    `-fizz.txt

• Der Testquellcode unter src / test / java, Platzieren Sie die Testressourcendateien unter "src / test / resources"

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

--pom.xml ist dasselbe wie für compiler: compile

Lauf

> mvn resources:testResources compiler:testCompile
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-cli) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-cli) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Ausführungsergebnis

|-pom.xml
|-src/test/
| :
`-target/
  `-test-classes/
    |-fizz.txt
    |-foo/
    | `-bar.txt
    `-example/
      `-HelloTest.class

• Die Ergebnisse werden unter "Ziel- / Testklassen" ausgegeben

――Wenn organisiert, ist die Operation wie folgt.

• Das Ziel von "testResources" besteht darin, die Dateien und Ordner unter "$ {project.basedir} / src / test / resources" nach "$ {project.basedir} / target / test-classes" zu kopieren.
• Ressourcenordner können mit " " angegeben werden
• Das Ziel "testCompile" kompiliert die Java-Quelldateien unter "$ {project.basedir} / src / test / java" und gibt sie an "$ {project.basedir} / target / test-classes" aus.
• Der Quellordner kann mit " " angegeben werden

Führen Sie den Test aus

--Nächste, um den kompilierten Testcode auszuführen, [Testziel](https: //) von maven-surefire-plugin maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html) wird ausgeführt.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.6.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.2</version>
      </plugin>
    </plugins>
  </build>
</project>

• Die folgenden Änderungen wurden vorgenommen, damit JUnit5 funktioniert.
• Den Abhängigkeiten wurde "junit-jupiter" hinzugefügt
• Geben Sie 2.22.2 für die Version des Maven-Surefire-Plugins an --2.22.0 oder höher muss angegeben werden, um JUnit5 verwenden zu können

Ordnerstruktur

|-pom.xml
`-src/
  |-main/java/
  | `-example/
  |   `-Hello.java
  `-test/java/
    `-example/
      `-HelloTest.java

• Platzieren Sie die Testzielklasse (Hello.java) und die Testklasse ( HelloTest.java)

Lauf

> mvn test
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ hello ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running example.HelloTest
...
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 s - in example.HelloTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

> dir /b target\surefire-reports
example.HelloTest.txt
TEST-example.HelloTest.xml

• Das Ziel "todsicher: Test" ist an die "Test" -Phase gebunden, daher wird es mit der angegebenen "Test" -Phase ausgeführt.
• Es ist möglich, safefire: test alleine auszuführen, aber in diesem Fall muss die Quelle separat kompiliert werden.
• Die auszuführende Testklasse wird in [Includes-Parameter] angegeben (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes). Die folgenden Klassen werden standardmäßig ausgeführt. Ist gezielt
  • **/Test*.java
  • **/*Test.java
  • **/*Tests.java
  • **/*TestCase.java --Testergebnisse werden im Text- und XML-Format unter "Ziel- / todsichere Berichte" gedruckt --Dies wird im Ziel "safefire: test" Berichtsparameter angegeben (Standard ist) $ {project.build.directory} / todsichere Berichte)

Überspringen Sie den Test

--Nach der "Test" -Phase wird die "Paket" -Phase ausgeführt, die das Kompilierungsergebnis des Projekts in einem Glas einfriert.

• Das heißt, die Testphase muss erfolgreich abgeschlossen sein, um ein Glas zu generieren.
• Wenn der Test in der Testphase fehlschlägt, wird die Paketphase nicht ausgeführt
• Es sollte sein, dass der Code, der den Test nicht bestanden hat, nicht verwendet werden kann, selbst wenn er in einem Glas verpackt ist. Leider gibt es Projekte, in denen der Testcode nicht gepflegt wird und der Test nicht bestanden wird.
• In solchen Fällen ist es üblich, die Ausführung der Testphase zu überspringen und die Paketphase auszuführen (was nicht der Fall sein sollte).

Ausführungsergebnis

> mvn -DskipTests package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ hello ---
[INFO] Tests are skipped.
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...

--surefire: test Das Ziel hat einen Parameter namens skipTests.

• Wenn dies eingestellt ist, wird die Testausführung übersprungen.

• Zusammenfassend lässt sich sagen, dass die Testphase Folgendes bewirkt:
• Der Testcode wird vom maven-surefire-plugin ausgeführt
• Um JUnit 5 verwenden zu können, muss die Version des Maven-Surefire-Plugins 2.22.0 oder höher sein.
• Die auszuführende Testklasse ist in [Includes-Parameter] angegeben (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#includes).
• Die Testergebnisse werden unter "Ziel- / Sicherheitsfeuer-Berichte" ([Parameter "ReportsDirectory") (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#reportsDirectory) "gedruckt. )
• Die Testausführung kann übersprungen werden, indem der Parameter [skipTests] festgelegt wird (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skipTests).
• Die Verwendung sollte jedoch auf ein Minimum beschränkt werden
• Der Test wird nicht gewartet und Sie benötigen jetzt ein Glas (die richtige Antwort besteht darin, ihn so zu reparieren, dass der Test erfolgreich ist).
• Der Test besteht, die Ausführung dauert jedoch lange, sodass er nicht jedes Mal ausgeführt werden kann. - etc

Im Glas aushärten

• Der Prozess der Verfestigung des Kompilierungsergebnisses in einem JAR ist das [JAR-Ziel](https: //maven.apache) des Maven-JAR-Plugins. .org / plugins / maven-jar-plugin / jar-mojo.html)

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Die für die Kompilierung erforderlichen Mindesteinstellungen

Ordnerstruktur

|-pom.xml
`-src/
  |-test/
  | :
  `-main/
    |-java/
    | `-example/
    |   `-Hello.java
    `-resources/
      `-hoge.txt

Führen Sie die Paketphase aus

> mvn package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ hello ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hello ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ hello ---
...
[INFO] --- maven-surefire-plugin:2.22.2:test (default-test) @ hello ---
...
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

• Das Ziel "jar: jar" ist an die "Paket" -Phase gebunden, sodass Sie die "Paket" -Phase ausführen.

Ausführungsergebnis

|-pom.xml
|-src/
| :
`-target/
  |-hello-1.0.0.jar
  :

--hello-1.0.0.jar wird direkt unter dem Ordner target ausgegeben.

• Das Ausgabeziel der JAR-Datei wird durch den Parameter outputDirectory des JAR-Ziels festgelegt.
• Der Standardwert für diesen Parameter ist "$ {project.build.directory}" ("$ {project.basedir} / target").
• Bei der Implementierung des JAR-Ziels lautet der Name der JAR-Datei auch finalName. /org/apache/maven/plugins/jar/AbstractJarMojo.java#L80) im Feld deklariert --Dieses Feld ist "readonly = true" und kann daher nicht direkt von außen geändert werden.
• Der Wert dieses Feldes wird auf "$ {project.build.finalName}" gesetzt --Dieser Wert wird von Super POM standardmäßig auf "$ {project.artifactId} - $ {project.version}" gesetzt.
• Wenn Sie das JAR umbenennen möchten, können Sie daher " " festlegen
• Wenn Sie dieses Glas entpacken, ist der Inhalt wie folgt

text:hello-1.0.0.Inhalt des Glases

|-hoge.txt
|-example/
| `-Hello.class
`-META-INF/
  |-MANIFEST.MF
  `-maven/example/hello/
    |-pom.properties
    `-pom.xml

--hoge.txt und Hello.class werden mit der Ausgabe unter target / classes von resources: resources bzw. compiler: compile gepackt. --Welcher Ordnerinhalt in ein JAR gepackt wird, wird durch den Parameter classesDirectory des JAR-Ziels festgelegt. Ist gewesen

• Der Standardwert für diesen Parameter ist "$ {project.build.outputDirectory}" ("$ {project.basedir} / target / classes"). --Pom.xml wird unter META-INF ausgegeben, aber der Inhalt ist der gleiche wie pom.xml dieses Projekts.
• "MANIFEST.MF" und "pom.properties" haben jeweils den folgenden Inhalt.

MANIFEST.MF

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.3
Built-By: xxxxx
Build-Jdk: 11.0.6

pom.properties

#Generated by Maven
#Sun Mar 29 21:59:48 JST 2020
groupId=example
artifactId=hello
version=1.0.0

--Diese werden im Parameter archive des JAR-Ziels festgelegt.

• Details zu den Archiveinstellungen finden Sie unter Apache Maven Archiver - Referenz. --Diese Dateien werden mit standardmäßig aktivierten Einstellungen generiert

• Zusammenfassend funktioniert das "jar" -Ziel folgendermaßen:
• Dateiname
  • ${project.artifactId}-${project.version}
• Geben Sie mit << project> an, um Änderungen vorzunehmen --Ausgabestandort
  • ${project.basedir}/target
• Geben Sie mit " " an, um Änderungen vorzunehmen
• Ziel verpacken
  • ${project.basedir}/target/classes
• Wenn Sie es ändern möchten, geben Sie es mit dem Parameter " " oder "classesDirectory" des Ziels "jar" an.
• Zusätzlich kann der Parameter "archive" verwendet werden, um die unter "MANIFEST.MF" und "META-INF" hinzugefügten Informationen festzulegen.

Im lokalen Repository installieren

• [Installationsziel](https: // maven.) Des maven-install-plugin, das der Installationsphase zugeordnet ist. apache.org/plugins/maven-install-plugin/install-mojo.html) bietet die Möglichkeit, Projektartefakte in einem lokalen Repository zu installieren.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
  ...
</project>

Führen Sie install aus

> mvn install
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

• Das Ziel "install: install" ist an die Phase "install" gebunden, sodass Sie die Phase "install" ausführen (verwirrend).
• Wenn die Ausführung abgeschlossen ist, überprüfen Sie im lokalen Repository
• Der Speicherort des lokalen Repositorys ist "% USERPROFILE% \ .m2 \ repository" unter Windows ("$ HOME / .m2 / repository" unter Linux). --Wenn Sie in settings.xml einen anderen Speicherort angegeben haben, diesen

Lokales Repository

Lokales Repository/
 |-example/
 : `-hello/
     |-1.0.0/
     : |-hello-1.0.0.jar
       :

• Die JAR-Datei wird im lokalen Repository gespeichert --Die zu registrierende JAR-Datei ist wahrscheinlich die JAR-Datei, die in der "Paket" -Phase generiert wurde. --install: install In der Zieldokumentation stand "Hauptartefakt des Projekts", aber ich konnte keine klare Beschreibung des Hauptartefakts des Projekts finden.
• In Bezug auf die Implementierung [MavenProject getArtifact ()](https://github.com/apache/maven/blob/maven-3.6.3/maven-core/src/main/java/org/apache/maven/project Artifact getFile (), erhältlich mit /MavenProject.java#L215) Ich konnte bis zu dem Punkt lesen, an dem die Datei, die von Apache / Maven / Artefakt / Artifact.java # L85 abgerufen werden kann, installiert zu sein scheint, aber ich konnte den Ort nicht finden, an dem dieses "Datei" -Objekt festgelegt ist

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>example</groupId>
      <artifactId>hello</artifactId>
      <version>1.0.0</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
    </plugins>
  </build>
</project>

• Deklarieren von Abhängigkeiten von hello-1.0.0.jar mit <Abhängigkeiten>

Foo.java

package example;

public class Foo {
    public static void main(String... args) {
        new Hello().hello();
    }
}

• Ich schreibe eine Implementierung, die die Klasse "Hallo" verwendet

Kompilieren Sie das Projekt

> mvn compile
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ foo ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ foo ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

--Kompiliert (Hallo Klasse wurde aufgelöst)

• Zusammenfassend funktioniert das Installationsziel folgendermaßen:
• Installieren Sie wahrscheinlich die in der Paketphase generierten Artefakte (z. B. JAR-Dateien) in Ihrem lokalen Repository --Installierte Artefakte werden als Abhängigkeiten von anderen lokalen Projekten angezeigt

Bereitstellen

• Die letzte Ausführung ist die Bereitstellungsphase

--deploy Goal stellt Projektartefakte in einem Remote-Repository bereit ―― Ich bin der Meinung, dass es nur wenige Möglichkeiten gibt, es tatsächlich zu verwenden, obwohl es schwierig ist, eine Umgebung zu erstellen. </ Del> Die Überprüfung wird weggelassen.

Erstellen Sie ein Webprojekt

Sehen Sie, wie Ihr Projekt erstellt wird, wenn Sie --packaging auf war setzen

• Das in der Standardphase ausgeführte Plug-In ist jedoch fast das gleiche wie im Fall von "jar".
• Der Unterschied zu "jar" besteht darin, dass das in der "Paket" -Phase ausgeführte Ziel [Krieg] ist (https://maven.apache.org/plugins/maven-war-plugin/) Kriegsziel

Ordnerstruktur

|-pom.xml
`-src/main/
  |-java/
  | `-example/webapp/
  |   `-HelloServlet.java
  `-webapp/
    `-WEB-INF/
      `-hello.jsp

--Erstellte einen Ordner mit dem Namen "src / main / webapp" und erstellte einen Ordner wie "WEB-INF", der in "war" darunter aufgenommen werden soll.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>webapp</artifactId>
  <version>1.0.0</version>
  <packaging>war</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>4.0.1</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>commons-lang3</artifactId>
      <version>3.10</version>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>3.2.3</version>
      </plugin>
    </plugins>
  </build>
</project>

--war ist angegeben für<packaging>

• Die folgenden beiden sind als Abhängigkeiten angegeben
  • Servlet API
  • Apache Commons Lang3

Bauen

> mvn package
...
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ webapp ---
...
[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ webapp ---
...
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ webapp ---
...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ webapp ---
...
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ webapp ---
...
[INFO] --- maven-war-plugin:3.2.3:war (default-war) @ webapp ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

• Wie im Fall von "jar" wird das Ziel des Plug-ins in jeder Phase ausgeführt und schließlich "war: war" ausgeführt.

Ausgabeergebnis

|-pom.xml
|-src/
| :
`-target/
  `-webapp-1.0.0.war

• Die Kriegsdatei wird direkt unter "Ziel" generiert
• Der Ausgabeort wird im [outputDirectory-Parameter] des war-Ziels angegeben (https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#outputDirectory) und ist standardmäßig$ Es ist {project.build.directory}
• Der Name der Kriegsdatei lautet warName. Es wird durch einen schreibgeschützten Parameter namens maven / plugins / war / WarMojo.java # L71) angegeben und ist standardmäßig "$ {project.build.finalName}".
• Der Inhalt von webapp-1.0.0.war ist wie folgt

text:webapp-1.0.0.Der Inhalt des Krieges

webapp-1.0.0.war/
|-WEB-INF/
| |-hello.jsp
| |-classes/
| | `-example/webapp/
| |   `-HelloServlet.class
| `-lib/
|   `-commons-lang3-3.10.jar
`-META-INF/
  |-MANIFEST.MF
  `-maven/example/webapp/
    |-pom.properties
    `-pom.xml

• Sie können sehen, dass das Kompilierungsergebnis von "src / main / java" und der Inhalt unter "src / main / webapp" in der Kriegsdatei enthalten sind.
• Platzieren Sie Dateien, die Sie außer Warendateien und Bibliotheksgläsern in den Krieg ziehen, im Ordner src / main / webapp. --Dies wird im [warSourceDirectory-Parameter] des war-Ziels angegeben (https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#warSourceDirectory) und ist standardmäßig $ { basedir} / src / main / webapp
• Außerdem wird das als Abhängigkeit angegebene Apache Commons Lang3-JAR unter "WEB-INF / lib" gespeichert. --Servlet-API-JAR wird nicht gespeichert
• Dies liegt daran, dass der Umfang der Abhängigkeit von der Servlet-API in "bereitgestellt" angegeben wurde.
• Detaillierte Erläuterungen zum Anwendungsbereich werden später beschrieben.

• Zusammenfassend wird das Projekt wie folgt erstellt, wenn die Verpackung "Krieg" ist:
• Grundsätzlich wie "Glas" gebaut
• Der Punkt, dass das Ziel "Krieg: Krieg" nur in der "Paket" -Phase ausgeführt wird, unterscheidet sich jedoch vom Fall "Glas".
• Im Ziel "Krieg: Krieg" wird das Kompilierungsergebnis des Projekts in einer Kriegsdatei ausgegeben.
• Zusätzlich zur Klassendatei, Ressource und abhängigen Bibliothek wird die Datei unter "src / main / webapp" auch so wie sie ist im Krieg gespeichert.

Führen Sie eine Java-Anwendung aus

Hello.java

package example;

import java.util.Arrays;

public class Hello {
    public static void main(String... args) {
        System.out.println("Hello World! args=" + Arrays.toString(args));
    }
}

• Hallo Welt, Implementierung, die Befehlszeilenargumente ausgibt

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.6.0</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>example.Hello</mainClass>
              <arguments>
                <argument>one</argument>
                <argument>two</argument>
                <argument>three</argument>
              </arguments>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

• Ein Plugin namens exec-maven-plugin wurde hinzugefügt.

Lauf

> mvn compile exec:java
...
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ hello ---
Hello World! args=[one, two, three]
...

--Hello.java wurde ausgeführt --Mit dem exec-maven-plugin Java-Ziel können Sie das Projekterstellungsergebnis in den Klassenpfad einfügen. Kann Java-Programme ausführen --exec-maven-plugin hat auch ein exec-Ziel, mit dem Sie beliebige Befehle ausführen können. Hier weggelassen

• mainClass Sie können Java-Programme ausführen, indem Sie die Main-Klasse mit dem Parameter angeben.
• Argumente Sie können Befehlszeilenargumente mit Parametern übergeben.
• Sie können auch ein Argument mit dem Parameter "commandlineArgs" übergeben, dies wird jedoch zur Ausführung über die später beschriebene Befehlszeile verwendet (wahrscheinlich).

Von der Befehlszeile ausführen

• Für das erste Beispiel müssen alle Ausführungskonfigurationen in pom.xml im Voraus beschrieben werden.
• In einigen Fällen möchten Sie es möglicherweise ausführen, während Sie verschiedene Argumente in der Befehlszeile ändern.
• In diesem Fall ist es einfacher, die Zielparameter über Systemeigenschaften anzugeben.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.6.0</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>example.Hello</mainClass>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

• Es ist mühsam, die Hauptklasse über die Befehlszeile anzugeben, daher denke ich, dass nur dies im Voraus in pom.xml beschrieben werden kann.

Ausführungsergebnis

> mvn compile exec:java -Dexec.args="ONE TWO THREE"
...
Hello World! args=[ONE, TWO, THREE]

• commandlineArgs Mit dem Parameter können Sie das Argument als durch Leerzeichen getrennte Zeichenfolge angeben.
• Wenn Sie in Systemeigenschaften angeben, geben Sie dies in "exec.args" an

Abhängigkeiten

Abhängigkeitsbereich

• Sie können eine Abhängigkeit namens ** Scope ** festlegen --Scope repräsentiert den Bereich, in dem die Abhängigkeit verwendet wird.
• Zum Beispiel gibt die im Bereich "Kompilieren" angegebene Abhängigkeit an, dass sie immer vom Zeitpunkt der Kompilierung des Quellcodes bis zur Ausführung der Anwendung verwendet wird.
• Auch die Abhängigkeit vom Bereich "test" gibt an, dass sie nur verwendet werden sollte, wenn der Testcode ("src / test / java") kompiliert und der Test ausgeführt wird.
• Es gibt 6 Arten von Bereichen wie folgt.
  • compile
  • provided
  • runtime
  • test
  • system
  • import

Kompilierungsbereich

pom.xml

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang3</artifactId>
  <version>3.10</version>
</dependency>

• Wenn kein Bereich angegeben ist, wird der Bereich "Kompilieren" standardmäßig übernommen (kann angegeben werden).
• Der Bereich "Kompilieren" gibt an, dass die Abhängigkeit von der Kompilierung bis zur Ausführung immer erforderlich ist.

vorgesehener Umfang

pom.xml

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <version>4.0.1</version>
  <scope>provided</scope>
</dependency>

• Der Bereich "bereitgestellt" gibt an, dass die Abhängigkeit von der Ausführungsumgebung bereitgestellt wird. --Verwenden Sie, wenn die folgenden Bedingungen erfüllt sind
• Zum Kompilieren und Testen erforderlich
• Die Ausführungsumgebung stellt das JAR jedoch zur Laufzeit bereit, sodass die Anwendung es nicht separat aufbewahren muss.
• Das häufigste Beispiel ist die Servlet-API.
• Die Servlet-API verwendet die vom Anwendungsserver bereitgestellte API, die den War bereitstellt, sodass die Anwendung zur Laufzeit keine individuellen Abhängigkeiten aufweisen muss.
• Geben Sie aus demselben Grund andere APIs (EJB, JAX-RS usw.) an, die von Java EE (Jakarta EE) mit "bereitgestellt" bereitgestellt werden.
• Wenn ein Krieg mit dem "Maven-War-Plugin" generiert wird, werden die in "Bereitgestellt" angegebenen Abhängigkeiten nicht unter "WEB-INF / lib" platziert.

Laufzeitbereich

pom.xml

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.2.12</version>
    <scope>runtime</scope>
</dependency>

• Der Bereich "Laufzeit" ist das Gegenteil von "Bereitgestellt" und wird mit Abhängigkeiten verwendet, die zur Kompilierungszeit nicht benötigt werden, aber zur Laufzeit benötigt werden.
• Ein typisches Beispiel ist der JDBC-Treiber.
• Wenn Sie ein Programm mit dem JDBC-Treiber schreiben, stellt die Implementierung java.sql.Connection Bereit, die von der Standard-API bereitgestellt wird. Sie müssen sich nur auf Klassen wie sql / java / sql / Connection.html verlassen.
• Grundsätzlich hängt es nicht direkt von den konkreten Klassen ab, die von jedem Datenbankprodukt bereitgestellt werden. ――Aber natürlich benötigen Sie zur Laufzeit eine Entität
• Dies gilt also für den Fall, dass es zur Kompilierungszeit nicht benötigt wird, aber zur Laufzeit benötigt wird.

Testumfang

pom.xml

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.6.1</version>
    <scope>test</scope>
</dependency>

--test scope wird für Abhängigkeiten verwendet, die nur beim Kompilieren und Ausführen der Testquelle verwendet werden.

• Kann nicht beim Kompilieren oder Ausführen des Hauptquellcodes verwendet werden
• Verwenden Sie Abhängigkeiten, die nur zum Testen benötigt werden, z. B. JUnit

Systemumfang

pom.xml

<dependency>
  <groupId>javax.sql</groupId>
  <artifactId>jdbc-stdext</artifactId>
  <version>2.0</version>
  <scope>system</scope>
  <systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

• Der Bereich "System" gibt an, dass die Abhängigkeit vom System bereitgestellt wird (JRE oder JDK der Ausführungsumgebung). --Dieser Bereich scheint für den Zweck vorbereitet zu sein, Erweiterungsbibliotheken zu verwenden, die sich nicht im Repository befinden und intern von JRE und JDK gespeichert werden.
• Wenn Sie den Bereich "system" angeben, müssen Sie den Pfad der Ziel-JAR-Datei mit "" angeben.
• Sie können auch eine Bibliothek in Ihrem Projekt haben, die nicht im Repository vorhanden ist, und diese als Referenz verwenden. ―― Ursprünglich ist es ein unkomplizierter Ansatz, ein privates Repository vorzubereiten und dort zu verwalten.
• Die Verwendung dieses Bereichs ist vorerst veraltet.
  • System Dependencies

Importbereich

Ordnerstruktur

|-foo/
| `-pom.xml
`-bar/
  `-pom.xml

• Es gibt zwei Projekte, foo und bar

pom.xml(foo)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>foo</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <dependencyManagement>
    <dependencies>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.10</version>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-text</artifactId>
          <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

• Das foo-Projekt setzt die Verpackung auf "pom" und deklariert nur ""
• Die folgenden beiden werden als abhängige Ziele deklariert.
  • org.apache.commons:commons-lang3:3.10
  • org.apache.commons:commons-text:1.8

pom.xml(bar)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>bar</artifactId>
  <version>1.0.0</version>

  <dependencyManagement>
    <dependencies>
      <dependency>
          <groupId>example</groupId>
          <artifactId>foo</artifactId>
          <version>1.0.0</version>
          <type>pom</type>
          <scope>import</scope>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.9</version>
      </dependency>
      <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-csv</artifactId>
          <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

• Im Balkenprojekt wird in "" das vorherige foo-Projekt im Bereich "import" angegeben.
• Der Bereich "Import" kann nur in "" angegeben werden
• Wenn Sie den Bereich "import" angeben, müssen Sie auch den Bereich " pom </ type>" angeben.
• Außerdem werden die folgenden zwei als andere abhängige Objekte deklariert.
  • org.apache.commons:commons-lang3:3.9
  • org.apache.commons:commons-csv:1.8
• Überprüfen Sie in diesem Zustand den "effektiven Pom" des Balkenprojekts.

effective-Bestätigung von pom(bar)

> cd bar

> mvn help:effective-pom
...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.9</version>
      </dependency>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-csv</artifactId>
        <version>1.8</version>
      </dependency>
      <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-text</artifactId>
        <version>1.8</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

--Derklärungen von Abhängigkeiten zum foo-Projekt sind verschwunden und stattdessen wurden die in <dependencyManagement> des foo-Projekts deklarierten Abhängigkeiten hinzugefügt.

• Wenn die Artefakte jedoch dupliziert werden, wird die Version des Balkenprojekts übernommen (commons-lang3).
• Wie Sie sehen können, hat "Import" einen speziellen Bereich zum Importieren (Importieren) von "" anderer POM-Projekte.

BOM

• Es gibt eine Methode namens ** Stückliste (Stückliste) **, die den Bereich "Import" als Methode zur Verwaltung der Abhängigkeitsversion für mehrere Projekte verwendet.
• Bereiten Sie für Stücklisten zuerst ein Stücklistenprojekt mit pom.xml vor.
• Die Datei pom.xml des Stücklistenprojekts deklariert "", wodurch die von jedem Projekt verwendeten Abhängigkeiten definiert werden.
• Importieren Sie für jedes Projekt dieses Stücklistenprojekt mit dem Bereich "Import"
• Die Abhängigkeitsversion wird im Stücklistenprojekt deklariert, sodass jedes Projekt nur "groupId" und "artefaktId" in "" deklarieren muss.
• Dadurch kann das Stücklistenprojekt die von allen Projekten verwendeten Abhängigkeitsversionen zentral verwalten.
• Übrigens ist die Stückliste von Spring Boot hier. 6.RELEASE.pom)
• Durch Laden dieser Stückliste können Sie die Version der verwendeten Bibliothek an die von Spring Boot unterstützte anpassen.

• Um die Reichweite jedes Bereichs aus der Vogelperspektive zu betrachten, habe ich eine Tabelle mit der Beziehung zwischen dem Bereich und dem Ziel erstellt (ausgeschlossen, da "Import" etwas Besonderes ist).

• Das ○ gibt an, dass sich das Ziel auf die Abhängigkeit des entsprechenden Bereichs bezieht und diese verwendet.
• Für war: war bedeutet dies, ob es in die generierte Kriegsdatei gepackt wird.
• Andernfalls bedeutet dies, ob es im Klassenpfad festgelegt ist oder nicht.

Überprüfen Sie die Abhängigkeiten im Baum

• Sie können die Abhängigkeit des Projekts überprüfen, indem Sie es in einem Baumstrukturdiagramm anzeigen.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>5.2.5.RELEASE</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-jdbc</artifactId>
      <version>5.2.5.RELEASE</version>
    </dependency>
  </dependencies>
</project>

• Deklarieren des Spring Framework-Webs und von jdbc als Abhängigkeiten ――Die Bibliothek, von der das Projekt abhängt, ist jedoch nicht darauf beschränkt, und tatsächlich hängt sie auch von der Bibliothek ab, von der spring-web und spring-jdbc abhängen.
• Sie können nicht einfach anhand von pom.xml erkennen, von wie vielen Bibliotheken Ihr Projekt letztendlich abhängt.
• Baumziel von maven-dependency-plugin Wenn Sie plugin / tree-mojo.html) ausführen, können Sie alle Abhängigkeiten einschließlich dieser Übergangsabhängigkeit im Diagramm der Baumstruktur sehen.

Ausführungsergebnis

> mvn dependency:tree
...
[INFO] +- org.springframework:spring-web:jar:5.2.5.RELEASE:compile
[INFO] |  +- org.springframework:spring-beans:jar:5.2.5.RELEASE:compile
[INFO] |  \- org.springframework:spring-core:jar:5.2.5.RELEASE:compile
[INFO] |     \- org.springframework:spring-jcl:jar:5.2.5.RELEASE:compile
[INFO] \- org.springframework:spring-jdbc:jar:5.2.5.RELEASE:compile
[INFO]    \- org.springframework:spring-tx:jar:5.2.5.RELEASE:compile
...

• Es ist zu sehen, dass "Spring-Web" weiter von "Spring-Beans", "Spring-Core" und "Spring-Core" von "Spring-Jcl" abhängt.
• Und Sie können sehen, dass spring-jdbc von spring-tx abhängt
• Übrigens hängt "spring-jdbc" auch von "spring-bean" und "spring-core" ab, aber die Anzeige wird weggelassen, da sie sich mit der "spring-web" -Seite überlappt.
• Standardmäßig werden die Abhängigkeiten aller Bereiche ausgegeben, Sie können sie jedoch auch durch [Bereichsparameter] eingrenzen (https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#scope). es kann

Sammeln Sie Abhängigkeitsgläser

• In seltenen Fällen möchten Sie alle tatsächlichen JAR-Dateien abrufen, von denen Ihr Projekt abhängt.
• Dies kann mit dem Ziel für Kopierabhängigkeiten von "Maven-Dependency-Plugin" erreicht werden.
• Versuchen Sie, mit den gleichen Einstellungen wie pom.xml in ↑ zu laufen

Ausführungsergebnis

> mvn dependency:copy-dependencies
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

> dir /b target\dependency
spring-beans-5.2.5.RELEASE.jar
spring-core-5.2.5.RELEASE.jar
spring-jcl-5.2.5.RELEASE.jar
spring-jdbc-5.2.5.RELEASE.jar
spring-tx-5.2.5.RELEASE.jar
spring-web-5.2.5.RELEASE.jar

• Alle abhängigen Gläser werden im Ordner "target / dependency" ausgegeben
• Standardmäßig werden Gläser aller Bereiche als Ziel ausgewählt, jedoch durch includeScope-Parameter usw. eingegrenzt. in der Lage sein

Profil

• Grundsätzlich ist es gut, das Projekt so zu erstellen, dass in jeder Umgebung dasselbe Ergebnis mit denselben Einstellungen ausgegeben wird. ――Der Build ist in einer Umgebung erfolgreich, in einer anderen Umgebung tritt jedoch ein Fehler auf, der problematisch ist. ―― Es scheint jedoch selten, dass während der tatsächlichen Entwicklung umgebungsabhängige Build-Einstellungen erforderlich sind (obwohl ich es nicht weiß).
• Wenn Sie den Inhalt von pom.xml abhängig von der Build-Umgebung ändern möchten (aktivieren Sie ein bestimmtes Plug-In oder ändern Sie den Einstellungswert), können Sie einen Mechanismus namens ** Profile ** verwenden.

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <profiles>
    <profile>
      <id>foo</id>

      <properties>
        <message>foo profile!!</message>
      </properties>

      <dependencies>
        <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-lang3</artifactId>
          <version>3.10</version>
        </dependency>
      </dependencies>

      <build>
        <directory>${project.basedir}/build</directory>
      </build>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>message = ${message}</echo>
            <echo>project.build.directory = ${project.build.directory}</echo>
            <echo>dependency[0] = ${project.dependencies[0].artifactId}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<profiles> <profile>deklariert ein Profil namens foo

• Das foo Profil legt Eigenschaften, Abhängigkeiten und project.build.directory fest.
• Ich benutze maven-antrun-plugin um diese Werte anzuzeigen.

Ausführungsergebnis

> mvn antrun:run
...
     [echo] message = ${message}
     [echo] project.build.directory = F:\tmp\maven\hello\target
     [echo] dependency[0] = ${project.dependencies[0].artifactId}
...

> mvn -P foo antrun:run
...
     [echo] message = foo profile!!
     [echo] project.build.directory = F:\tmp\maven\hello\build
     [echo] dependency[0] = commons-lang3

• Bei normaler Ausführung werden die im foo -Profil festgelegten Inhalte nicht wiedergegeben.
• Wenn Sie andererseits "-P foo" angeben und ausführen, können Sie sehen, dass die im "foo" -Profil festgelegten Inhalte wiedergegeben werden.
• Auf diese Weise können Sie mithilfe eines Profils Einstellungen definieren, die nur gelten, wenn Sie dieses Profil verwenden.
• Die Profildefinition wird durch "" beschrieben
• Legen Sie einen Namen fest, um das Profil eindeutig mit "" zu identifizieren
• Andernfalls können Sie die Elemente, die in pom.xml beschrieben werden können (<Abhängigkeiten>, <build> usw.), so wie sie sind beschreiben.
• Um das Profil anzugeben, geben Sie in der Befehlszeile "-P" gefolgt von "" des Profils an.

Geben Sie mehrere Profile an und führen Sie sie aus

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <properties>
        <foo>FOO</foo>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <bar>BAR</bar>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.8</version>
        <configuration>
          <target>
            <echo>foo = ${foo}</echo>
            <echo>bar = ${bar}</echo>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Deklarieren von zwei Profilen, "foo" und "bar" --message wird in beiden Profilen als dupliziert deklariert

Ausführungsergebnis

> mvn -P bar,foo antrun:run
...
     [echo] foo = FOO
     [echo] bar = BAR
     [echo] message = bar profile!!

• Wenn Sie mehrere Profile angeben, listen Sie die durch Kommas getrennten IDs auf.
• Doppelte Elemente scheinen später in pom.xml übernommen zu werden (es scheint nicht in der im Profil angegebenen Reihenfolge zu sein).

Profil standardmäßig aktivieren

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Das foo Profil wird auf <activeByDefault> true </ activeByDefault> gesetzt

Ausführungsergebnis

> mvn antrun:run
...
     [echo] message = foo profile!!
...

> mvn -P bar antrun:run
...
     [echo] message = bar profile!!

• Die Eigenschaft foo ist standardmäßig aktiviert
• Wenn Sie " " auf "true" setzen, wird das Profil standardmäßig aktiviert.
• Wenn mit -P ein anderes Profil angegeben wird, ist das Profil mit <activeByDefault> is true ungültig.

Profil nur aktivieren, wenn die Bedingungen erfüllt sind

Aktivieren Sie die Systemeigenschaften, wenn sie deklariert sind

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <activation>
        <property>
          <name>foo</name>
        </property>
      </activation>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Deklarieren von "" in ""

Ausführungsergebnis

> mvn antrun:run
...
     [echo] message = ${message}
...

> mvn -Dfoo antrun:run
...
     [echo] message = foo profile!!

• Das Profil wird nicht durch "-P" angegeben, aber das "foo" -Profil wird aktiviert, indem die Systemeigenschaft mit "-Dfoo" deklariert wird.
• In <Aktivierung> können Sie die Bedingungen definieren, um das Profil zu aktivieren. --<Eigenschaft>kann unter der Bedingung angegeben werden, dass eine Systemeigenschaft deklariert oder ein bestimmter Wert festgelegt wird.
• Hier wird nur " foo </ name>" festgelegt. Wenn also die Systemeigenschaft "foo" festgelegt ist, ist das Profil unabhängig vom Wert gültig. --Wenn der Wert auch eine Bedingung ist, deklarieren Sie "" wie folgt:

Wenn der Wert der Systemeigenschaft ebenfalls in der Bedingung enthalten ist

        <property>
          <name>foo</name>
          <value>enable</value>
        </property>

Ausführungsergebnis

> mvn -Dfoo antrun:run
...
     [echo] message = ${message}
...

> mvn mvn -Dfoo=enable antrun:run
...
     [echo] message = foo profile!!

• Das foo Profil ist nur aktiviert, wenn der Wert der Systemeigenschaft foo`` enable ist.

Konditioniert auf die JDK-Version

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>jdk11</id>
      <activation>
        <jdk>11</jdk>
      </activation>
      <properties>
        <message>jdk11 profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>jdk14</id>
      <activation>
        <jdk>14</jdk>
      </activation>
      <properties>
        <message>jdk14 profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Sie verwenden das Element in

Ausführungsergebnis

> java --version
openjdk 11.0.6 2020-01-14
...

> mvn antrun:run
...
     [echo] message = jdk11 profile!!
...

> java --version
openjdk 14 2020-03-17
...

> mvn antrun:run
...
     [echo] message = jdk14 profile!!

• Das Profil wurde zur Laufzeit entsprechend der JDK-Version gewechselt.
• Sie können <jdk> verwenden, um die Java-Version zur Laufzeit zu einer Bedingung für die Profilanwendung zu machen.
• Die in <jdk> beschriebene Bedingung ist präfixangepasst und wird mit der Java-Version verglichen.
• Wenn Sie "11" angeben, stimmt dies auch mit "11.0.6" überein, da es sich um eine Präfixübereinstimmung handelt.
• Außerdem können Sie eine Bereichsspezifikation wie "(, 11]" schreiben (in diesem Fall entspricht sie 11 oder niedrigeren Versionen).
• Informationen zum Schreiben von Bereichsspezifikationen finden Sie unter Integrierte Regeln für Apache Maven Enforcer - Spezifikation des Versionsbereichs.
• Der von der Systemeigenschaft "java.version" erhaltene Wert wird für die zu vergleichende Java-Version verwendet.
• Die Implementierung ist wahrscheinlich dies Aktivierung / JdkVersionProfileActivator.java # L66) --Die Bedingung kann abgelehnt werden, indem "!" Vorangestellt wird, z. B. "! 11 </ jdk>".

Konditionieren Sie das Betriebssystem

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>Windows</id>
      <activation>
        <os>
          <name>Windows 10</name>
        </os>
      </activation>
      <properties>
        <message>Windows profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>Linux</id>
      <activation>
        <os>
          <name>Linux</name>
        </os>
      </activation>
      <properties>
        <message>Linux profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<Aktivierung>ist auf<os>gesetzt

Ausführungsergebnis(Windows)

> mvn antrun:run
...
     [echo] message = Windows profile!!

Ausführungsergebnis(Linux)

> mvn antrun:run
...
     [echo] message = Linux profile!!

• Das angewendete Profil wird je nach Betriebssystem zur Laufzeit gewechselt. --<os>ermöglicht die Verwendung des Betriebssystems als Bedingung für die Profilanwendung zur Laufzeit --<Name>hängt vom Namen des Betriebssystems ab
• Der Betriebssystemname verwendet den Wert, der von der Systemeigenschaft "os.name" abgerufen werden kann. ――Es scheint keinen Unterschied zwischen Groß- und Kleinschreibung zu geben
• Zusätzlich zum Namen können Sie die folgenden Bedingungen angeben
  • <family> --OS Typ
• Eine Liste möglicher Werte finden Sie unter Integrierte Regeln für Apache Maven Enforcer - Betriebssystemversion erforderlich.
• Übrigens, für Linux geben Sie "Unix" an
  • <arch>
• CPU-Architektur
• Geben Sie "x86" oder "amd64" an
  • <version> --OS Version
• Wenn Sie mehrere dieser Bedingungen angeben, werden alle mit der UND-Bedingung kombiniert.
• Der Wert der aktuellen Umgebung finden Sie im [Display-Info-Ziel](http: /) des Maven-Enforcer-Plugins. Sie können dies überprüfen, indem Sie /maven.apache.org/enforcer/maven-enforcer-plugin/display-info-mojo.html ausführen.

Ausführungsergebnis

> mvn enforcer:display-info
...
[INFO] Maven Version: 3.6.3
[INFO] JDK Version: 11.0.6 normalized as: 11.0.6
[INFO] OS Info: Arch: amd64 Family: windows Name: windows 10 Version: 10.0

Das Vorhandensein der Datei ist eine Bedingung

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>Exists</id>
      <activation>
        <file>
          <exists>${basedir}/pom.xml</exists>
        </file>
      </activation>
      <properties>
        <message>Exists profile!!</message>
      </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        ...
        <configuration>
          <target>
            <echo>message = ${message}</echo>
          </target>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• "" gibt "" an

Ausführungsergebnis

> mvn antrun:run
...
     [echo] message = Exists profile!!

• Sie können "" verwenden, um das Vorhandensein oder Fehlen einer Datei als Bedingung für das Anwenden eines Profils zu verwenden. --<exists>wird unter der Bedingung festgelegt, dass die Datei vorhanden ist --Verwenden Sie "", wenn die Bedingung besteht, dass die Datei nicht vorhanden ist
• In der Dateipfadspezifikation lautet der eingebettete Parameter $ {basedir} oder Systemeigenschaft / Anforderungseigenschaft? Es gibt eine Einschränkung, dass es nur verwendet werden kann
• Wenn Sie "$ {project.basedir} / pom.xml" schreiben, wird dies nicht gut beurteilt.

Überprüfen Sie die verfügbaren Profile

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <profiles>
    <profile>
      <id>foo</id>
      <properties>
        <message>foo profile!!</message>
      </properties>
    </profile>
    <profile>
      <id>bar</id>
      <properties>
        <message>bar profile!!</message>
      </properties>
    </profile>
  </profiles>

  ...
</project>

--foo, bar, zwei Profile sind definiert

Ausführungsergebnis

> mvn help:all-profiles
...
[INFO] Listing Profiles for Project: example:hello:jar:1.0.0
  Profile Id: bar (Active: false , Source: pom)
  Profile Id: foo (Active: false , Source: pom)

• alle Profile in maven-help-plugin -plugin / all-profile-mojo.html), um zu sehen, welche Profile verfügbar sind

Überprüfen Sie das aktive Profil

Ausführungsergebnis

> mvn -P foo help:active-profiles antrun:run
...
Active Profiles for Project 'example:hello:jar:1.0.0':

The following profiles are active:

 - foo (source: example:hello:1.0.0)
...
     [echo] message = foo profile!!

--Verwenden Sie aktive Profile, um festzustellen, welche Profile zur Laufzeit aktiv sind. es kann ――Es kann beim Debuggen hilfreich sein

Wann wird das Profil verwendet?

• Mit Profilen können Sie für jedes Profil unterschiedliche Erstellungsergebnisse erstellen ―― Aus diesem Grund können verschiedene Entwickler unterschiedliche Build-Ergebnisse erzielen, wenn das Profil zu unterschiedlich ist.
• Es gab eine Regel wie "Für Entwicklungszwecke müssen Sie das" Entwicklungs "-Profil aktivieren und vergessen, es anzugeben.
• Änderungen in den Build-Ergebnissen können Verwirrung stiften
• Wie Sie sich aus der Tatsache vorstellen können, dass Bedingungen wie "" festgelegt werden können, besteht der ursprüngliche Zweck des Profils darin, die Unterschiede in der Umgebung zu absorbieren, in der der Build ausgeführt wird. ―― Deshalb denke ich, dass es besser ist, es so weit wie möglich für andere Zwecke zu vermeiden (persönliche Meinung).
• Beispielsweise wird das Profil möglicherweise nicht zum Wechseln der Einstellungsdatei verwendet, die für die Entwicklungs-, Verifizierungs- und Produktionsumgebung verwendet wird.
• Ich halte es heutzutage für eine bewährte Methode, Umgebungsvariablen zu verwenden, um die App-Einstellungen für jede Umgebung zu ändern.
• Referenz: III. Einstellungen | Die Zwölf-Faktoren-App (japanische Übersetzung)

Mach deinen eigenen Stecker

• Sie können Ihr eigenes Plug-In erstellen --Wenn die Plugins in org.apache.maven.plugins oder com.codehaus.mojo Ihre Ziele nicht erreichen, müssen Sie Ihre eigenen erstellen.

Hello World

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
  <packaging>maven-plugin</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-plugin-api</artifactId>
      <version>3.6.3</version>
    </dependency>

    <dependency>
      <groupId>org.apache.maven.plugin-tools</groupId>
      <artifactId>maven-plugin-annotations</artifactId>
      <version>3.6.0</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-plugin-plugin</artifactId>
        <version>3.6.0</version>
      </plugin>
    </plugins>
  </build>
</project>

• Setzen Sie die Verpackung auf "Maven-Plugin" --Stellen Sie die folgenden zwei als Abhängigkeiten ein
  • org.apache.maven:maven-plugin-api
  • org.apache.maven.plugin-tools:maven-plugin-annotations --Dies ist im "bereitgestellten" Bereich angegeben --Einstellen von maven-plugin-plugin
• Wenn Sie versuchen, mit Java 11 zu kompilieren, wird anscheinend eine Fehlermeldung angezeigt, es sei denn, Sie aktualisieren die Version dieses Plug-Ins.

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Mojo;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {

    public void execute() throws MojoExecutionException {
        getLog().info("Hello Custom Plugin!");
    }
}

--Erstellen Sie eine Klasse, indem Sie die AbstractMojo -Klasse erben

• Diese HelloPlugin-Klasse entspricht einem Ziel
• Implementieren Sie die Verarbeitung des Plug-Ins in der Methode execute ()
• Die Ziel-Metainformationen werden mit der Annotation "@ Mojo" festgelegt. --name wird der Name des Ziels

Bauen

> mvn install
...

• Führen Sie die Installationsphase aus, um das erstellte Plugin in Ihrem lokalen Repository zu installieren
• Versuchen Sie es mit dem installierten Plug-In in einem anderen Projekt

pom.xml(Weitere Projekte)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
    </plugins>
  </build>
</project>

• Das "Hallo-Maven-Plugin" ist auf "" gesetzt

Ausführungsergebnis

> mvn hello:hello
...
[INFO] Hello Custom Plugin!

• Ich konnte mein eigenes Plug-In ausführen

Plugin Name (ArtefaktId)

pom.xml

...
  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
...

• Es ist üblich, "Artefakt-ID" Ihres eigenen Plug-Ins auf "XXX-Maven-Plugin" zu setzen.
• Wenn Sie "Artefakt-ID" auf dieses Muster setzen, wird die Meta-Definition automatisch mit dem Teil "XXX" als Präfix des Plug-Ins erstellt.
• Probieren Sie die erstellte JAR-Datei aus

Inhalt des Glases

hello-1.0.0.jar/
 |-example/
 `-META-INF/
   |-MANIFEST.MF
   `-maven/
     |-example/
     `-plugin.xml

• Wenn man sich den Inhalt dieser plugin.xml ansieht, sieht es so aus:

plugin.xml

...
<plugin>
  <name>hello-maven-plugin</name>
  <description></description>
  <groupId>example</groupId>
  <artifactId>hello-maven-plugin</artifactId>
  <version>1.0.0</version>
  <goalPrefix>hello</goalPrefix>
  <isolatedRealm>false</isolatedRealm>
  <inheritedByDefault>true</inheritedByDefault>
...

--<goalPrefix>ist jetzt hallo

• Dadurch kann diesem Plug-In das Präfix "Hallo: " vorangestellt werden
• Wenn Sie eine "Artefakt-ID" namens "foo-maven-plugin" haben, lautet das Präfix "foo".

Mojo

• Die Klasse, die die Ziele von Mavens Plug-In implementiert, heißt ** Mojo (Maven Old Java Object) **.
• Beim Lesen von Mavens Dokumentation erscheint hier und da der Begriff Mojo. ――In diesem Fall können Sie sich eine Klasse vorstellen, die Ziele umsetzt.

Parameter definieren

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• Hinzufügen eines "Nachrichten" -Felds zu Mojo und Kommentieren mit "@ Parameter"
• Getter und Setter sind nicht definiert

pom.xml(Ein weiteres Projekt)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <configuration>
          <message>Hello World!!</message>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

--<Konfiguration>deklariert dasselbe Element wie der Mojo-Feldname

Ausführungsergebnis

> mvn hello:hello
...
[INFO] message = Hello World!!

• Das in Mojo deklarierte Feld message kann jetzt als Parameter angegeben werden.
• Übrigens können Sie in diesem Zustand den Wert nicht in den Systemeigenschaften angeben.

Ermöglichen die Angabe von Parametern in den Systemeigenschaften

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(property="hello.message")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• Setzen Sie die Eigenschaft von @ Parameter auf den in den Systemeigenschaften angegebenen Namen.

pom.xml (separates Projekt)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
...

• Geben Sie nicht an (wenn es festgelegt ist, hat dies Vorrang)

Ausführungsergebnis

> mvn hello:hello -Dhello.message="HELLO WORLD!!"
...
[INFO] message = HELLO WORLD!!

• Sie können den Wert jetzt über die Systemeigenschaften einstellen

Legen Sie Standardwerte für Parameter fest

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(property="hello.message", defaultValue="Hello Custom Plugin!!")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• Sie können den Standardwert für diesen Parameter mit der Annotation @ Parameter`` defaultValue deklarieren.

pom.xml(Ein weiteres Projekt)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
...

--<Konfiguration>ist nicht konfiguriert

Ausführungsergebnis

> mvn hello:hello
...
[INFO] message = Hello Custom Plugin!!
...

> mvn hello:hello -Dhello.message=OVERRIDE!!
...
[INFO] message = OVERRIDE!!

• Wenn nichts festgelegt ist, können Sie sehen, dass der in defaultValue festgelegte Wert übernommen wird.

Verwenden Sie einen Ausdruck für den Standardwert

HelloMojo.java

package example;
...

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter(defaultValue="${hello.mojo.message}")
    private String message;

    public void execute() throws MojoExecutionException {
        getLog().info("message = " + message);
    }
}

• Für den Wert von "defaultValue" können Sie einen Ausdruck wie "$ {...}" schreiben
• Siehe PluginParameterExpressionEvaluator Javadoc für Werte, auf die in Ausdrücken verwiesen werden kann.
• Sie können auch auf Systemeigenschaften und Projekteigenschaften verweisen (<Eigenschaften>).

pom.xml(Ein weiteres Projekt)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <properties>
    <hello.mojo.message>Project Property</hello.mojo.message>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
    </plugins>  
  </build>
</project>

• Deklarieren eines Werts in <Eigenschaften> mit demselben Schlüssel, der im Ausdruck defaultValue deklariert wurde

Ausführungsergebnis

> mvn hello:hello
...
[INFO] message = Project Property
...

> mvn hello:hello -Dhello.mojo.message="System Property"
...
[INFO] message = System Property

--Der in <Eigenschaften> deklarierte Wert wird im Parameter messge festgelegt

• Kann auch mit Systemeigenschaften überschrieben werden

Typen, die für Parameter verwendet werden können

--Parametertypen können mit verschiedenen Typen deklariert werden, nicht nur mit "String"

HelloMojo.java

package example;

import java.io.File;
import java.net.URL;
import java.util.Date;
import java.util.List;
import java.util.Map;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.logging.Log;
import org.apache.maven.plugins.annotations.Mojo;
import org.apache.maven.plugins.annotations.Parameter;

@Mojo(name="hello")
public class HelloMojo extends AbstractMojo {
    @Parameter
    private int intValue;
    @Parameter
    private long longValue;
    @Parameter
    private boolean booleanValue;
    @Parameter
    private double doubleValue;
    @Parameter
    private Date dateValue;
    @Parameter
    private File fileValue;
    @Parameter
    private URL urlValue;
    @Parameter
    private HelloEnum enumValue;
    @Parameter
    private List<String> listValues;
    @Parameter
    private Map<String, String> mapValue;

    public void execute() throws MojoExecutionException {
        Log log = getLog();
        log.info("intValue=" + intValue);
        log.info("longValue=" + longValue);
        log.info("booleanValue=" + booleanValue);
        log.info("doubleValue=" + doubleValue);
        log.info("dateValue=" + dateValue);
        log.info("fileValue=" + fileValue);
        log.info("urlValue=" + urlValue);
        log.info("enumValue=" + enumValue);
        log.info("listValues=" + listValues);
        log.info("mapValue=" + mapValue);
    }

    public enum HelloEnum {
        HELLO,
        WORLD;
    }
}

• Parameter werden mit verschiedenen Typen definiert

pom.xml(Ein weiteres Projekt)

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <configuration>
          <intValue>123</intValue>
          <longValue>1234567890</longValue>
          <booleanValue>true</booleanValue>
          <doubleValue>1234.5678</doubleValue>
          <dateValue>2019-10-20 12:13:14</dateValue>
          <fileValue>foo/bar</fileValue>
          <urlValue>https://www.google.co.jp/</urlValue>
          <enumValue>HELLO</enumValue>
          <listValues>
            <aaa>fizz</aaa>
            <bbb>buzz</bbb>
          </listValues>
          <mapValue>
            <foo>FOO</foo>
            <bar>BAR</bar>
          </mapValue>
        </configuration>
      </plugin>
    </plugins>  
  </build>
</project>

Ausführungsergebnis

> mvn hello:hello
...
[INFO] intValue=123
[INFO] longValue=1234567890
[INFO] booleanValue=true
[INFO] doubleValue=1234.5678
[INFO] dateValue=Sun Oct 20 12:13:14 JST 2019
[INFO] fileValue=F:\tmp\maven\hello\foo\bar
[INFO] urlValue=https://www.google.co.jp/
[INFO] enumValue=HELLO
[INFO] listValues=[fizz, buzz]
[INFO] mapValue={bar=BAR, foo=FOO}
...

• Primitive Typen wie "int", "long", "float", "double" und "boolean" können normal verwendet werden. --Wrapper-Klasse ist ebenfalls möglich --java.util.Date wird in einem der folgenden Formate angegeben
• JJJJ-MM-TT HH: mm: ss.S a (Beispiel: 2005-10-06 2:22: 55.1 PM) --yyyy-MM-dd HH: mm: ssa (Beispiel: 2005-10-06 2:22:55 PM) ――Jedoch können sie flexibel analysiert werden, auch wenn sie nicht genau übereinstimmen (AM und PM können weggelassen werden, aber die Zeit kann nicht weggelassen werden). --java.io.File behandelt den Wert als Pfad --java.net.URL behandelt den Wert als URL
• Im Fall eines Aufzählungstyps kann dieser festgelegt werden, indem derselbe Wert wie für die aufgelisteten Konstanten angegeben wird.
• Wenn Sie im Fall von "List" Elemente mit beliebigen Namen auflisten, während Sie dasselbe Element wie den Parameternamen schreiben, wird es anscheinend als Element von "List" verarbeitet.
• Normalerweise ist es einfacher, als " ..." zu schreiben
• Im Fall von "Map" ist der Name des verschachtelten Elements der Schlüssel und der Wert des Elements der Wert.
• Obwohl die Überprüfung weggelassen wurde, kann "java.util.Properties" auf die gleiche Weise verwendet werden.

Ordnen Sie die Standardphase zu

HelloMojo.java

package example;

import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugins.annotations.LifecyclePhase;
import org.apache.maven.plugins.annotations.Mojo;

@Mojo(name="hello", defaultPhase=LifecyclePhase.VALIDATE)
public class HelloMojo extends AbstractMojo {

    public void execute() throws MojoExecutionException {
        getLog().info("Hello Mojo!!");
    }
}

• Sie können die Standardphase mit defaultPhase von @ Mojo angeben
• Verwenden Sie den Aufzählungstyp "LifecyclePhase", um die Phase anzugeben
• Hier ist es mit der "Validierungs" -Phase verbunden

pom.xml(Ein weiteres Projekt)

...
      <plugin>
        <groupId>example</groupId>
        <artifactId>hello-maven-plugin</artifactId>
        <version>1.0.0</version>
        <executions>
          <execution>
            <goals>
              <goal>hello</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
...

--hello Nur das Ziel wird deklariert und die Phasen sind nicht miteinander verbunden.

Ausführungsergebnis(Ein weiteres Projekt)

> mvn validate
...
[INFO] Hello Mojo!!

• Das "Hallo" -Ziel wird in der Ausführung der "Validierungs" -Phase ausgeführt.

Löschen Sie das Produkt

Ordnerstruktur

|-pom.xml
`-target/

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>example</groupId>
  <artifactId>hello</artifactId>
  <version>1.0.0</version>
</project>

Ausführungsergebnis

> mvn clean
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hello ---
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Ordnerstruktur (nach Ausführung)

`-pom.xml

• sauberes Ziel von maven-clean-plugin Sie können alle Projektprodukte entfernen, indem Sie plugin / clean-mojo.html ausführen.
• Hier wird die "saubere" Phase angegeben.
• Das "saubere" Ziel ist standardmäßig mit der "sauberen" Phase verbunden (verwirrend).
• Standardmäßig werden die folgenden Ordner zum Löschen ausgewählt
  • ${project.build.directory}
  • ${project.build.outputDirectory}
  • ${project.build.testOutputDirectory}
  • ${project.reporting.outputDirectory} -- $ {project.basedir} / target wird gelöscht, sofern Sie den Pfad des obigen Ordners nicht geändert haben.

Fügen Sie den zu löschenden Ordner hinzu

Ordnerstruktur

|-pom.xml
|-target/
`-foo/

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project ...>
  ...

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-clean-plugin</artifactId>
        <version>3.1.0</version>
        <configuration>
          <filesets>
            <fileset>
              <directory>${project.basedir}/foo</directory>
            </fileset>
          </filesets>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

• Hinzufügen von <Dateisätzen> und Hinzufügen des zu löschenden Ordners foo

Ausführungsergebnis

> mvn clean
...
[INFO] --- maven-clean-plugin:3.1.0:clean (default-clean) @ hello ---
[INFO] Deleting ...\foo (includes = [], excludes = [])
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Ordnerstruktur (nach Ausführung)

`-pom.xml

• Nicht nur "Ziel", sondern "Foo" wurde gelöscht
• Sie können Ordner und Dateien hinzufügen, die mit [Dateigruppenparameter] gelöscht werden sollen (https://maven.apache.org/plugins/maven-clean-plugin/clean-mojo.html#filesets). --<Datensätze>gibt die Sammlung von [Dateigruppe] an (https://maven.apache.org/plugins/maven-clean-plugin/apidocs/org/apache/maven/plugins/clean/Fileset.html) Machen
• Es scheint, dass Sie die Dateien nicht nur mit "", sondern auch mit "" und "" eingrenzen können (ich habe es nicht ausprobiert).

Referenz und offizielles Inhaltsverzeichnis des Dokuments

Es ist zu schwierig zu verstehen, wo und welche Informationen sich befinden, daher werde ich sie klären </ del>

• POM
  • Maven – POM Reference
  • Maven – Introduction to the POM
  • Maven Model Builder – Super POM
  • Apache Maven Archiver – Reference
• Plugin
  • Maven – Available Plugins
  • Maven – Guide to Configuring Plug-ins
  • Maven – Guide to Developing Java Plugins
  • Mojo – Plugins
• Lebenszyklus erstellen
  • Maven – Introduction to the Build Lifecycle
  • Lifecycle Reference
  • Maven Core – Plugin Bindings for Default Lifecycle Reference --Profil
  • Maven – Introduction to build profiles
• Abhängigkeitsauflösung
  • Maven – Introduction to the Dependency Mechanism --Folderstruktur
  • Maven – Introduction to the Standard Directory Layout
• Javadoc
  • Maven Model API