Apache Maven Tutorial

1. Einführung

Das Erstellen eines Softwareprojekts umfasst in der Regel Aufgaben wie das Herunterladen von Abhängigkeiten, das Hinzufügen zusätzlicher Jars auf einem Klassenpfad, das Kompilieren von Quellcode in Binärcode, Ausführen von Tests, Packen von kompiliertem Code in bereitstellbare Artefakte wie JAR-, WAR- und ZIP-Dateien sowie das Bereitstellen dieser Artefakte zu einem Anwendungsserver oder Repository.

Apache Maven automatisiert diese Aufgaben, minimiert das Risiko, dass Menschen Fehler beim manuellen Erstellen der Software verursachen, und trennt die Arbeit des Kompilierens und Packens unseres Codes von der der Codekonstruktion.

In diesem Lernprogramm werden wir dieses leistungsstarke Werkzeug zum Beschreiben, Erstellen und Verwalten von Java-Softwareprojekten anhand einer zentralen, in XML geschriebenen Information, dem Project Object Model (POM), erkunden.

2. Warum Maven benutzen?

Die Hauptmerkmale von Maven sind:

Einfaches Projekt-Setup mit Best Practices: Maven versucht dies

Vermeiden Sie so viele Konfigurationen wie möglich, indem Sie Projektvorlagen bereitstellen (benannt archetypes ) Abhängigkeitsmanagement: ** es beinhaltet automatische Aktualisierung und Herunterladen

und Validierung der Kompatibilität sowie Berichterstattung über die Abhängigkeit Schließungen (auch als transitive Abhängigkeiten bezeichnet) Isolation zwischen Projektabhängigkeiten und Plugins: ** mit Maven,

Projektabhängigkeiten werden aus den dependency-Repositorys abgerufen. Alle Abhängigkeiten des Plugins werden vom __plugin abgerufen Repositorys, die zu weniger Konflikten führen, wenn Plugins gestartet werden Laden Sie zusätzliche Abhängigkeiten herunter zentrales Repository-System: ** Projektabhängigkeiten können aus geladen werden

das lokale Dateisystem oder öffentliche Repositorys, wie Maven Central

Um zu erfahren, wie Sie Maven auf Ihrem System installieren können, klicken Sie auf den Link:/install-maven-on-windows-linux-mac[dieses Tutorial auf Baeldung]. **

3. Projektobjektmodell

Die Konfiguration eines Maven-Projekts erfolgt über ein Project Object Model (POM) , dargestellt durch eine pom.xml -Datei. Der POM beschreibt das Projekt, verwaltet Abhängigkeiten und konfiguriert Plugins zum Erstellen der Software.

Der POM definiert auch die Beziehungen zwischen Modulen von Multimodulprojekten. Schauen wir uns die grundlegende Struktur einer typischen POM -Datei an:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
           //...
            </plugin>
        </plugins>
    </build>
</project>

Schauen wir uns diese Konstrukte genauer an.

3.1. Projektkennungen

Maven verwendet eine Reihe von Bezeichnern, auch Koordinaten genannt, um ein Projekt eindeutig zu identifizieren und anzugeben, wie das Projektartefakt verpackt werden soll:

groupId - ein eindeutiger Basisname der Firma oder Gruppe, die erstellt wurde

das Projekt ** artifactId - ein eindeutiger Name des Projekts

version - eine Version des Projekts
packaging - eine Paketierungsmethode (z. B. WAR / JAR / ZIP )

Die ersten drei davon ( groupId: artifactId: version ) bilden zusammen den eindeutigen Bezeichner und geben den Mechanismus an, mit dem Sie angeben, welche Versionen von externen Bibliotheken (z. B. JARs) Ihr Projekt verwenden wird.

3.2. Abhängigkeiten

Diese externen Bibliotheken, die ein Projekt verwendet, werden Abhängigkeiten genannt.

Die Abhängigkeitsverwaltung in Maven gewährleistet den automatischen Download dieser Bibliotheken aus einem zentralen Repository, sodass Sie sie nicht lokal speichern müssen.

Dies ist ein Hauptmerkmal von Maven und bietet die folgenden Vorteile:

** verbraucht weniger Speicher, indem die Anzahl der Downloads erheblich reduziert wird

aus entfernten Repositories macht das Auschecken eines Projekts schneller

** bietet eine effektive Plattform für den Austausch binärer Artefakte

Ihre Organisation und darüber hinaus, ohne jedes Mal Artefakte aus der Quelle erstellen zu müssen **

Um eine Abhängigkeit von einer externen Bibliothek zu deklarieren, müssen Sie die groupId, die artifactId und die version der Bibliothek angeben.

Schauen wir uns ein Beispiel an:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.3.5.RELEASE</version>
</dependency>

Wenn Maven die Abhängigkeiten verarbeitet, wird die Spring Core-Bibliothek in Ihr lokales Maven-Repository heruntergeladen.

3.3. Repositories

Ein Repository in Maven wird zum Erstellen von Artefakten und Abhängigkeiten verschiedener Typen verwendet. Das lokale Standard-Repository befindet sich im Ordner .m2/repository im Home-Verzeichnis des Benutzers.

Wenn im lokalen Repository ein Artefakt oder ein Plug-In verfügbar ist, verwendet Maven es. Andernfalls wird es von einem zentralen Repository heruntergeladen und im lokalen Repository gespeichert. Das zentrale Standard-Repository lautet Maven Central .

Einige Bibliotheken wie der JBoss-Server sind nicht im zentralen Repository, sondern in einem alternativen Repository verfügbar. Für diese Bibliotheken müssen Sie die URL zum alternativen Repository in der Datei pom.xml angeben:

<repositories>
    <repository>
        <id>JBoss repository</id>
        <url>http://repository.jboss.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

Bitte beachten Sie, dass Sie in Ihren Projekten mehrere Repositorys verwenden können. **

3.4. Eigenschaften

Benutzerdefinierte Eigenschaften können dazu beitragen, dass Ihre pom.xml -Datei leichter zu lesen und zu verwalten ist. Im klassischen Anwendungsfall würden Sie benutzerdefinierte Eigenschaften verwenden, um Versionen für die Abhängigkeiten Ihres Projekts zu definieren.

Maven-Eigenschaften sind Platzhalter für Werte und können überall in einer pom.xml mit der Notation $ \ {name} ** aufgerufen werden, wobei name die Eigenschaft ist.

Sehen wir uns ein Beispiel an:

<properties>
    <spring.version>4.3.5.RELEASE</spring.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>
</dependencies>

Wenn Sie jetzt Spring auf eine neuere Version aktualisieren möchten, müssen Sie nur den Wert im Eigenschaftstag _ <spring.version> ändern. Alle Abhängigkeiten, die diese Eigenschaft in ihren Tags <version> _ verwenden, werden aktualisiert.

Eigenschaften werden auch häufig zur Definition von Buildpfadvariablen verwendet:

<properties>
    <project.build.folder>${project.build.directory}/tmp/</project.build.folder>
</properties>

<plugin>
   //...
    <outputDirectory>${project.resources.build.folder}</outputDirectory>
   //...
</plugin>

3.5. Bauen

Der build -Abschnitt ist auch ein sehr wichtiger Abschnitt des Maven POM. Er enthält Informationen zum Standard-Maven goal , zum Verzeichnis des kompilierten Projekts und zum endgültigen Namen der Anwendung. Der Standardabschnitt build sieht folgendermaßen aus:

<build>
    <defaultGoal>install</defaultGoal>
    <directory>${basedir}/target</directory>
    <finalName>${artifactId}-${version}</finalName>
    <filters>
      <filter>filters/filter1.properties</filter>
    </filters>
   //...
</build>

Der Standardausgabeordner für kompilierte Artefakte hat den Namen target , und der endgültige Name des verpackten Artefakts besteht aus artifactId und version . Sie können ihn jedoch jederzeit ändern.

**3.6. Profiles verwenden**

Eine weitere wichtige Funktion von Maven ist die Unterstützung von profiles. Ein profile besteht im Wesentlichen aus einer Reihe von Konfigurationswerten. Mit profiles können Sie den Build für verschiedene Umgebungen wie z. B. Produktion/Test/Entwicklung anpassen:

<profiles>
    <profile>
        <id>production</id>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
    </profile>
    <profile>
        <id>development</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <build>
            <plugins>
                <plugin>
               //...
                </plugin>
            </plugins>
        </build>
     </profile>
 </profiles>

Wie Sie im obigen Beispiel sehen können, ist das Standardprofil auf development gesetzt. Wenn Sie das production profile ausführen möchten, können Sie den folgenden Maven-Befehl verwenden:

mvn clean install -Pproduction

4. Maven Build Lifecycles

Jeder Maven-Build folgt einem angegebenen Lifecycle . Sie können mehrere Build lifecycle goals ausführen, einschließlich derer zum Erstellen des Projektcodes compile , Erstellen eines package, und install der Archivdatei im lokalen Maven-Abhängigkeits-Repository.

4.1. Lebenszyklusphasen

Die folgende Liste zeigt die wichtigsten Maven Lifecycle -Phasen:

validate - prüft die Richtigkeit des Projekts
compile - kompiliert den bereitgestellten Quellcode in binäre Artefakte
test - führt Komponententests aus
package - packt den kompilierten Code in eine Archivdatei
integration-test - führt zusätzliche Tests aus, für die der

Verpackung ** verify - prüft, ob das Paket gültig ist

install - Installiert die Paketdatei im lokalen Maven-Repository
deploy - Stellt die Paketdatei auf einem Remote-Server oder-Repository bereit

4.2. Plugins und Goals

Ein Maven plugin ist eine Sammlung von einem oder mehreren goals . Ziele werden in Phasen ausgeführt, wodurch die Reihenfolge bestimmt wird, in der die goals ausgeführt werden.

Die umfassende Liste der offiziell von Maven unterstützten Plugins ist verfügbar unter here . ** Es gibt auch einen interessanten Artikel zum Verknüpfen von:/executable-jar-with-maven[Erstellen einer ausführbaren Datei JAR bei Baeldung]mithilfe verschiedener Plugins.

Um zu verstehen, welche Ziele in welchen Phasen standardmäßig ausgeführt werden, lesen Sie http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in Lifecycle Bindings Maven Lifecycle -Bindungen].

Um eine der oben genannten Phasen zu durchlaufen, müssen Sie nur einen Befehl aufrufen:

mvn <phase>

Beispielsweise entfernt mvn clean install die zuvor erstellten Jar/war/zip-Dateien und kompilierten Klassen ( clean) und führt alle für die Installation des neuen Archivs ( install) erforderlichen Phasen aus.

Bitte beachten Sie, dass goals von plugins mit verschiedenen Phasen des Lifecycle verknüpft werden kann. **

5. Dein erstes Maven-Projekt

In diesem Abschnitt verwenden wir die Befehlszeilenfunktionalität von Maven, um ein Java-Projekt zu erstellen.

5.1. Einfaches Java-Projekt generieren

Führen Sie den folgenden Befehl aus, um ein einfaches Java-Projekt zu erstellen:

mvn archetype:generate
  -DgroupId=org.baeldung
  -DartifactId=org.baeldung.java
  -DarchetypeArtifactId=maven-archetype-quickstart
  -DinteractiveMode=false

Die groupId ist ein Parameter, der die Gruppe oder Person angibt, die ein Projekt erstellt hat. Dies ist häufig ein umgekehrter Domänenname der Firma. ArtifactId ist der im Projekt verwendete Basispaketname, und wir verwenden den Standard archetype .

Da wir die Version und den Verpackungstyp nicht angegeben haben, werden diese auf Standardwerte gesetzt. Die Version wird auf 1.0-SNAPSHOT, und die Verpackung auf jar gesetzt.

Wenn Sie nicht wissen, welche Parameter anzugeben sind, können Sie immer _interactiveMode = true_ angeben, sodass Maven alle erforderlichen Parameter abfragt. **

Nachdem der Befehl abgeschlossen ist, haben wir ein Java-Projekt, das eine App.java -Klasse enthält. Dies ist nur ein einfaches "Hello World" -Programm im Ordner src/main/java .

Wir haben auch eine Beispieltestklasse in src/test/java . Die pom.xml dieses Projekts sieht folgendermaßen aus:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung.java</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>org.baeldung.java</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.1.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Wie Sie sehen, wird standardmäßig die junit -Abhängigkeit bereitgestellt.

5.2. Projekt kompilieren und verpacken

Der nächste Schritt ist das Projekt zu kompilieren:

mvn compile

Maven durchläuft alle lifecycle -Phasen, die von der compile -Phase benötigt werden, um die Projektquellen zu erstellen. Wenn Sie nur die test -Phase ausführen möchten, können Sie Folgendes verwenden:

mvn test

Nun rufen wir die package phase _, auf, die die kompilierte Archivdatei jar_ erzeugt:

mvn package

5.3. Anwendung ausführen

Schließlich werden wir unser Java-Projekt mit dem exec-maven-plugin ausführen. Lassen Sie uns die notwendigen Plugins in der pom.xml konfigurieren:

<build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.6.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.5.0</version>
            <configuration>
                <mainClass>org.baeldung.java.App</mainClass>
            </configuration>
        </plugin>
    </plugins>
</build>

Das erste Plugin, maven-compiler-plugin , ist für die Kompilierung des Quellcodes unter Verwendung verantwortlich Java-Version 1.8. Https://search.maven.org/classic/#search%7Cga%7C1%7Ca%3A%22exec-maven-plugin%22[ exec-maven-plugin ]sucht in unserem Projekt nach der mainClass .

Um die Anwendung auszuführen, führen wir den folgenden Befehl aus:

mvn exec:java

6. Multi-Modul-Projekte

Der Mechanismus in Maven, der Projekte mit mehreren Modulen (auch aggregator -Projekte) behandelt, heißt Reactor .

Der Reactor sammelt alle verfügbaren Module, die erstellt werden sollen, sortiert die Projekte in der richtigen Reihenfolge und erstellt sie schließlich einzeln.

Hier erfahren Sie, wie Sie ein übergeordnetes Projekt mit mehreren Modulen erstellen.

6.1. Elternprojekt erstellen

Zunächst müssen wir ein übergeordnetes Projekt erstellen. Um ein neues Projekt mit dem Namen __parent-project anzulegen, verwenden wir den folgenden Befehl:

mvn archetype:generate -DgroupId=org.baeldung -DartifactId=parent-project

Als Nächstes aktualisieren wir den Verpackungstyp in der Datei pom.xml , um anzuzeigen, dass es sich um ein parent -Modul handelt:

<packaging>pom</packaging>

6.2. Submodul-Projekte erstellen

Im nächsten Schritt erstellen wir Submodul-Projekte aus dem Verzeichnis von parent-project :

cd parent-project
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=core
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=service
mvn archetype:generate -DgroupId=org.baeldung  -DartifactId=webapp

Um zu überprüfen, ob wir die Submodule richtig erstellt haben, schauen wir in die Datei parent-project pom.xml , in der wir drei Module sehen sollten:

<modules>
    <module>core</module>
    <module>service</module>
    <module>webapp</module>
</modules>

Darüber hinaus wird in jedem pom.xml -Submodul ein übergeordneter Abschnitt hinzugefügt

<parent>
    <groupId>org.baeldung</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>

6.3. Aktivieren der Abhängigkeitsverwaltung in übergeordneten Projekten

Abhängigkeitsmanagement ist ein Mechanismus zum Zentralisieren der Abhängigkeitsinformationen für ein Muti-Modul-Elternprojekt und dessen Kinder.

Wenn Sie über eine Reihe von Projekten oder Modulen verfügen, die ein gemeinsames übergeordnetes Element erben, können Sie alle erforderlichen Informationen zu den Abhängigkeiten in die allgemeine Datei pom.xml einfügen. Dadurch werden die Verweise auf die Artefakte in den untergeordneten __POM __s vereinfacht.

Schauen wir uns das Beispiel pom.xml eines Elternteils an:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>4.3.5.RELEASE</version>
        </dependency>
       //...
    </dependencies>
</dependencyManagement>

Durch die Deklaration der spring-core -Version im übergeordneten Element können alle von spring-core abhängigen Submodule die Abhängigkeit nur mit groupId und artifactId deklarieren, und die Version wird vererbt:

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
    </dependency>
   //...
</dependencies>

Darüber hinaus können Sie Ausschlüsse für die Abhängigkeitsverwaltung in pom.xml des übergeordneten Objekts angeben, sodass bestimmte Bibliotheken nicht von untergeordneten Modulen geerbt werden:

<exclusions>
    <exclusion>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
    </exclusion>
</exclusions>

Wenn ein untergeordnetes Modul eine andere Version einer verwalteten Abhängigkeit verwenden muss, können Sie die verwaltete Version in der pom.xml -Datei des Kindes überschreiben:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.2.1.RELEASE</version>
</dependency>

Beachten Sie, dass untergeordnete Module zwar von ihrem übergeordneten Projekt erben, ein übergeordnetes Projekt jedoch nicht notwendigerweise über Module verfügt, die es zusammenfasst. Andererseits kann ein übergeordnetes Projekt auch Projekte zusammenfassen, die nicht von ihm erben. **

Weitere Informationen zu Vererbung und Aggregation finden Sie in dieser Dokumentation ( https://maven.apache.org/pom.html#Aggregation [please).

6.4. Aktualisieren der Submodule und Erstellen eines Projekts

Wir können den packaging -Typ jedes Submoduls ändern. Ändern wir beispielsweise das packaging des webapp -Moduls in WAR , indem Sie die pom.xml -Datei aktualisieren:

<packaging>war</packaging>

Jetzt können wir den Build unseres Projekts mithilfe des Befehls mvn clean install testen. Die Ausgabe der Maven-Protokolle sollte folgendermaßen aussehen:

----[INFO]Scanning for projects...[INFO]Reactor build order:[INFO]  parent-project[INFO]  core[INFO]  service[INFO]  webapp//.............[INFO]-----------------------------------------[INFO]Reactor Summary:[INFO]-----------------------------------------[INFO]parent-project .................. SUCCESS[2.041s][INFO]core ............................ SUCCESS[4.802s][INFO]service ......................... SUCCESS[3.065s][INFO]webapp .......................... SUCCESS[6.125s][INFO]-----------------------------------------
----

7. Fazit

In diesem Artikel haben wir einige der beliebtesten Funktionen des Apache Maven Build-Tools beschrieben.

Alle Codebeispiele in Baeldung werden mit Maven erstellt. Sie können also einfach auf unserer https://github.com/eugenp/tutorials/tree/master/maven [GitHub-Projekt-Website nach verschiedenen Maven-Konfigurationen suchen.

TOC