1.1 Liste der in Maven zu erstellenden Plugins

Die Assembly in Maven kann sehr flexibel konfiguriert werden. Maven-Entwickler haben eigens Dutzende Plugins erstellt, mit denen Sie verschiedene Builds sehr flexibel konfigurieren können. Die beliebtesten davon sind in der folgenden Tabelle aufgeführt:

Plugin Beschreibung
1 Maven-Compiler-Plugin Verwaltet die Java-Kompilierung
2 Maven-Ressourcen-Plugin Steuert die Einbeziehung von Ressourcen in eine Assembly
3 Maven-Source-Plugin Steuert, ob Quellcode in einer Assembly enthalten ist
4 Maven-Abhängigkeits-Plugin Steuert den Prozess des Kopierens von Abhängigkeitsbibliotheken
5 Maven-Jar-Plugin Plugin zum Erstellen der endgültigen JAR-Datei
6 Maven War-Plugin Plugin zum Erstellen der endgültigen Kriegsdatei
7 maven-surefire-plugin Verwaltet Testläufe
8 Buildnummer-Maven-Plugin Erzeugt eine Build-Nummer

Jedes Plugin ist auf seine Art interessant, aber wir müssen sie alle analysieren. Beginnen wir mit der Hauptsache – dem Kompilierungsverwaltungs-Plugin.

1.2 Kompilierungs-Plugin Maven-Compiler-Plugin

Das beliebteste Plugin, mit dem Sie die Version des Compilers steuern können und das in fast allen Projekten verwendet wird, ist maven-compiler-plugin. Es verfügt über Standardeinstellungen, die jedoch in fast jedem Projekt erneut festgelegt werden müssen.

In der einfachsten Variante müssen Sie im Plug-in die Version des Java-Quellcodes und die Version der Java-Maschine angeben, unter der die Assembly durchgeführt wird:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <source>1.11</source>
        <target>1.13</target>
        <encoding>UTF-8</encoding>
    </configuration>
</plugin>

Im obigen Beispiel legen wir drei Java-Compiler-Optionen fest: source, targetund encoding.

Mit dem Parameter sourcekönnen wir die Java-Version für unsere Quellen festlegen. Der Parameter targetist die Version der Java-Maschine, unter der Sie die Klassen kompilieren möchten. Wenn kein Code oder keine Java-Machine-Version angegeben ist, ist der Standardwert 1.3

Schließlich encodingkönnen Sie mit dem Parameter die Kodierung von Java-Dateien festlegen. Wir haben darauf hingewiesen UTF-8. Mittlerweile sind fast alle Quellen in gespeichert UTF-8. Wenn dieser Parameter jedoch nicht angegeben ist, wird die aktuelle Kodierung des Betriebssystems ausgewählt. Für Windows ist dies die Kodierung Windows-1251.

Es gibt auch Fälle, in denen auf dem Build-Computer mehrere Java-Versionen installiert sind: um verschiedene Module und/oder verschiedene Projekte zu erstellen. In diesem Fall JAVA_HOMEkann in der Variablen nur der Pfad zu einem davon angegeben werden.

Darüber hinaus gibt es verschiedene Implementierungen der Java-Maschine: OpenJDK, OracleJDK, Amazon JDK. Und je größer das Projekt, desto komplexer ist seine Struktur. Sie können den Pfad zum Javac-Compiler für das Plugin jedoch mithilfe des Tags explizit festlegen . Es wurde speziell für diesen Anlass hinzugefügt.

Das Plugin maven-compiler-pluginhat zwei Ziele:

  • compiler:compile– Kompilierung von Quellen, standardmäßig mit der Kompilierungsphase verbunden
  • compiler:testCompile– Kompilierung von Tests, standardmäßig ist sie mit der Test-Kompilierungsphase verbunden.

Sie können auch eine Liste von Argumenten angeben, die an den Javac-Compiler in der Befehlszeile übergeben werden sollen:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
        <compilerArgs>
            <arg>-verbose</arg>
            <arg>-Xlint:all,-options,-path<arg>
        </compilerArgs>
    </configuration>
</plugin>

1.3 Plugin zum Erstellen einer JAR-Datei maven-jar-plugin

Wenn Sie mit Maven eine eigene JAR-Bibliothek erstellen möchten, benötigen Sie das Maven-Jar-Plugin. Dieses Plugin macht viele nützliche Dinge.

Ein Beispiel für ein solches Plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <includes>
            <include>**/properties/*</include>
        </includes>
        <archive>
           <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>

Erstens kann damit festgelegt werden, welche Dateien in die Bibliothek aufgenommen werden und welche nicht. Mithilfe von Tags <include>im Abschnitt <includes>können Sie eine Liste von Verzeichnissen angeben, deren Inhalt der Bibliothek hinzugefügt werden muss .

Zweitens muss jedes JAR ein Manifest haben ( MANIFEST.MF- Datei ). Das Plugin selbst platziert es an der richtigen Stelle in der Bibliothek. Sie müssen lediglich angeben, welchen Pfad es nehmen soll. Hierzu wird der Tag verwendet <manifestFile>.

Schließlich kann das Plugin selbst ein Manifest generieren. Dazu <manifestFile>müssen Sie anstelle eines Tags ein Tag hinzufügen <manifest>und darin Daten für das zukünftige Manifest angeben. Beispiel:

<configuration>
    <archive>
        <manifest>
            <addClasspath>true</addClasspath>
            <classpathPrefix>lib/</classpathPrefix>
            <mainClass>com.codegym.MainApplication</mainClass>
        </manifest>
    </archive>
</configuration>

Das Tag <addClasspath>gibt an, ob es zum Manifest hinzugefügt werden soll CLASSPATH.

Mit dem Tag <classpathPrefix>können Sie vor jeder Ressource ein Präfix (in der Beispielbibliothek) hinzufügen. Durch die Angabe eines Präfixes <classpathPrefix>können Sie Abhängigkeiten in einem separaten Ordner platzieren.

Ja, Sie können Bibliotheken in einer anderen Bibliothek platzieren. Und es warten viele Überraschungen auf Sie, wenn Sie irgendwo den Pfad zur Eigenschaftendatei übergeben müssen, die sich in der JAR-Bibliothek befindet, die sich in der JAR-Bibliothek befindet.

Schließlich <mainClass>verweist das Tag auf die ausführbare Hauptklasse. „Was ist die wichtigste ausführbare Klasse? ", - du fragst. Und die Sache ist, dass eine Java-Maschine ein Programm ausführen kann, das nicht nur durch eine Java-Klasse, sondern auch durch eine JAR-Datei spezifiziert wird. Und für diesen Fall wird die Hauptstartklasse benötigt.

1.4 Build-Nummern-Generierungs-Plugin buildnumber-maven-plugin

Sehr oft enthalten JAR-Bibliotheken und WAR-Dateien Informationen mit dem Namen des Projekts und seiner Version sowie der Version der Assembly. Dies ist nicht nur nützlich für die Verwaltung von Abhängigkeiten, sondern vereinfacht auch das Testen: Es ist klar, in welcher Version der Bibliothek der Fehler behoben ist und in welcher er hinzugefügt wurde.

Meistens wird diese Aufgabe so gelöst: Sie erstellen eine spezielle Datei application.properties, die alle erforderlichen Informationen enthält, und fügen sie in die Baugruppe ein. Sie können das Build-Skript auch so konfigurieren, dass die Daten aus dieser Datei nach MANIFEST.MFusw. migriert werden.

Am interessantesten ist jedoch, dass Maven über ein spezielles Plugin verfügt, das eine solche application.properties-Datei generieren kann. Dazu müssen Sie eine solche Datei erstellen und diese mit speziellen Datenvorlagen füllen. Beispiel:

# application.properties
app.name=${pom.name}
app.version=${pom.version}
app.build=${buildNumber}

Die Werte aller drei Parameter werden in der Build-Phase ersetzt.

Parameter pom.nameund pom.versionwerden direkt aus übernommen pom.xml. Und um in Maven eine eindeutige Build-Nummer zu generieren, gibt es ein spezielles Plugin – buildnumber-maven-plugin. Siehe Beispiel unten:

<packaging>war</packaging>
<version>1.0</version>
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <version>1.2</version>
        <executions>
            <execution>
                <phase>validate</phase>
                <goals>
                    <goal>create</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <revisionOnScmFailure>true</revisionOnScmFailure>
            <format>{0}-{1,date,yyyyMMdd}</format>
            <items>
                 <item>${project.version}</item>
                 <item>timestamp</item>
            </items>
        </configuration>
    </plugin>
</plugins>

Im obigen Beispiel passieren drei wichtige Dinge. Zunächst wird das Plugin selbst zum Festlegen der Assembly-Version angegeben . Zweitens wird angegeben, dass es während der Validierungsphase (der allerersten Phase) ausgeführt wird und eine Build-Nummer generiert – ${buildNumber}.

Und drittens wird das Format dieser Baugruppennummer angegeben, die aus mehreren Teilen zusammengeklebt wird . Dies ist die Version des Projekts project.versionund die aktuelle Uhrzeit, die in der Vorlage angegeben sind. Das Vorlagenformat wird durch die Java-Klasse angegeben MessageFormat.