Tutoriel Apache Maven

1. Introduction

La création d’un projet logiciel comprend généralement des tâches telles que le téléchargement de dépendances, l’ajout de fichiers JAR sur un chemin d’accès aux classes, la compilation du code source en code binaire, l’exécution de tests, la compression du code compilé dans des artefacts déployables tels que les fichiers JAR, WAR et ZIP, et le déploiement de ces artefacts. sur un serveur d’applications ou un référentiel.

Apache Maven automatise ces tâches, minimise le risque d’erreur humaine lors de la construction manuelle du logiciel et sépare le travail de compilation et de compression de notre code de celui de la construction de code.

Dans ce didacticiel, nous allons explorer ce puissant outil de description, de construction et de gestion de projets logiciels Java à l’aide d’une information centrale, le Project Object Model (POM) - écrite en XML.

2. Pourquoi utiliser Maven?

Les principales caractéristiques de Maven sont les suivantes:

Configuration simple du projet qui suit les meilleures pratiques: Maven essaie de

éviter autant que possible la configuration, en fournissant des modèles de projet (nommé archetypes ) gestion des dépendances: ** inclut la mise à jour automatique, le téléchargement

et valider la compatibilité, ainsi que signaler la dépendance fermetures (également appelées dépendances transitives) isolation entre les dépendances du projet et les plugins: ** avec Maven,

les dépendances du projet sont extraites des référentiels dependency tandis que toutes les dépendances du plugin sont extraites du fichier plugin référentiels, résultant en moins de conflits lorsque les plugins commencent à télécharger des dépendances supplémentaires système de référentiel central: ** les dépendances du projet peuvent être chargées à partir de

le système de fichiers local ou les référentiels publics, tels que Maven Central

Pour savoir comment installer Maven sur votre système, veuillez vérifier le lien:/install-maven-sur-windows-linux-mac[ce tutoriel sur Baeldung]. **

3. Modèle d’objet de projet

La configuration d’un projet Maven est effectuée via un POM (Project Object Model) , représenté par un fichier pom.xml . Le POM__ décrit le projet, gère les dépendances et configure les plugins pour la construction du logiciel.

Le POM définit également les relations entre les modules de projets multi-modules. Examinons la structure de base d’un fichier POM typique:

<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>

Examinons de plus près ces constructions.

3.1. Identifiants de projet

Maven utilise un ensemble d’identifiants, également appelés coordonnées, pour identifier de manière unique un projet et spécifier la manière dont l’artefact de projet doit être empaqueté:

groupId - un nom de base unique de la société ou du groupe qui a créé

le projet ** artifactId - un nom unique du projet

version - une version du projet
packaging - une méthode d’empaquetage (par exemple WAR / JAR / ZIP )

Les trois premiers ( groupId: artifactId: version ) se combinent pour former l’identificateur unique et constituent le mécanisme par lequel vous spécifiez les versions des bibliothèques externes (par exemple, les JAR) utilisées par votre projet.

3.2. Dépendances

Ces bibliothèques externes utilisées par un projet s’appellent des dépendances.

La fonctionnalité de gestion des dépendances de Maven assure le téléchargement automatique de ces bibliothèques à partir d’un référentiel central. Vous n’avez donc pas besoin de les stocker localement.

Ceci est une fonctionnalité clé de Maven et offre les avantages suivants:

** utilise moins de stockage en réduisant considérablement le nombre de téléchargements

hors dépôts distants accélère la vérification d’un projet

** fournit une plateforme efficace pour l’échange d’artefacts binaires au sein de

votre organisation et au-delà sans qu’il soit nécessaire de créer un artefact à partir de la source à chaque fois **

Pour déclarer une dépendance à une bibliothèque externe, vous devez fournir les éléments groupId, artifactId et version de la bibliothèque.

Prenons un exemple:

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

Lorsque Maven traite les dépendances, il télécharge la bibliothèque Spring Core dans votre référentiel Maven local.

3.3. Dépôts

Un référentiel dans Maven est utilisé pour contenir des artefacts de construction et des dépendances de types variés. Le référentiel local par défaut se trouve dans le dossier .m2/repository , sous le répertoire de base de l’utilisateur.

Si un artefact ou un plug-in est disponible dans le référentiel local, Maven l’utilise. Sinon, il est téléchargé depuis un référentiel central et stocké dans le référentiel local. Le référentiel central par défaut est Maven Central .

Certaines bibliothèques, telles que le serveur JBoss, ne sont pas disponibles dans le référentiel central mais sont disponibles dans un autre référentiel. Pour ces bibliothèques, vous devez fournir l’URL du référentiel alternatif dans le fichier pom.xml :

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

Veuillez noter que vous pouvez utiliser plusieurs référentiels dans vos projets. **

3.4. Propriétés

Les propriétés personnalisées peuvent faciliter la lecture et la maintenance de votre fichier pom.xml . Dans le cas d’utilisation classique, vous utiliseriez des propriétés personnalisées pour définir les versions des dépendances de votre projet.

Les propriétés Maven sont des espaces réservés aux valeurs et sont accessibles n’importe où dans un pom.xml en utilisant la notation $ \ {nom} ** , où name est la propriété.

Voyons un exemple:

<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>

Désormais, si vous souhaitez mettre à niveau Spring vers une version plus récente, il vous suffit de modifier la valeur dans la balise de propriété _ <version.version> et toutes les dépendances utilisant cette propriété dans leurs balises <version> _ seront mises à jour.

Les propriétés sont également souvent utilisées pour définir des variables de chemin de construction:

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

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

3.5. Construire

La section build est également une section très importante du Maven POM. . Elle fournit des informations sur le Maven goal par défaut, le répertoire du projet compilé et le nom final de l’application. La section build par défaut ressemble à ceci:

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

Le dossier de sortie par défaut pour les artefacts compilés s’appelle target et le nom final de l’artefact empaqueté est constitué de artifactId et de version , mais vous pouvez le modifier à tout moment. **

3.6. Utiliser Profiles

Une autre caractéristique importante de Maven est sa prise en charge de profiles. Un profile est fondamentalement un ensemble de valeurs de configuration. En utilisant profiles , vous pouvez personnaliser la construction pour différents environnements tels que Production/Test/Développement:

<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>

Comme vous pouvez le constater dans l’exemple ci-dessus, le profil par défaut est défini sur development . Si vous souhaitez exécuter production profile , vous pouvez utiliser la commande Maven suivante:

mvn clean install -Pproduction

4. Cycle de vie Maven Build

Chaque construction Maven suit un cycle de vie spécifié. Vous pouvez exécuter plusieurs build lifecycle goals , y compris ceux pour compiler le code du projet, créer un package, et install le fichier d’archive dans le référentiel de dépendances Maven local.

4.1. Phases du cycle de vie

La liste suivante répertorie les phases les plus importantes de Maven cycle de vie :

validate - vérifie l’exactitude du projet
compile - compile le code source fourni en artefacts binaires
test - exécute des tests unitaires
package - empaquete le code compilé dans un fichier archive
integration-test - exécute des tests supplémentaires nécessitant la

emballage ** verify - vérifie si le paquet est valide

install - installe le fichier de package dans le référentiel Maven local
deploy - déploie le fichier de package sur un serveur ou un référentiel distant

4.2. Plugins et Goals

Un plugin Maven est une collection d’un ou plusieurs objectifs. Les objectifs sont exécutés par phases, ce qui permet de déterminer l’ordre d’exécution des

La liste complète des plugins officiellement pris en charge par Maven est disponible à l’adresse here . Il existe également un article intéressant sur la manière de lier:/executable-jar-with-maven[construire un exécutable JAR sur Baeldung]à l’aide de divers plugins.

Pour mieux comprendre quels goals sont exécutés dans quelles phases par défaut, consultez le http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in Lifecycle Bindings[default Liaisons Maven lifecycle ].

Pour passer par l’une des phases ci-dessus, il suffit d’appeler une commande:

mvn <phase>

Par exemple, mvn clean install supprimera les fichiers jar/war/zip créés précédemment et les classes compilées ( clean) et exécutera toutes les phases nécessaires à l’installation de la nouvelle archive ( install) .

Veuillez noter que les objectifs fournis par plugins peuvent être associés à différentes phases du cycle de vie __. **

5. Votre premier projet Maven

Dans cette section, nous allons utiliser la fonctionnalité de ligne de commande de Maven pour créer un projet Java.

5.1. Générer un projet Java simple

Pour construire un projet Java simple, exécutons la commande suivante:

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

GroupId est un paramètre indiquant le groupe ou l’individu ayant créé un projet, qui est souvent un nom de domaine de société inversé. ArtifactId est le nom du package de base utilisé dans le projet et nous utilisons le type archetype standard.

Comme nous n’avons pas spécifié la version et le type d’emballage, celles-ci seront définies sur les valeurs par défaut. La version sera définie sur 1.0-SNAPSHOT, et l’emballage sur jar .

Si vous ne connaissez pas les paramètres à fournir, vous pouvez toujours spécifier _interactiveMode = true_ afin que Maven demande tous les paramètres requis. **

Une fois la commande terminée, nous avons un projet Java contenant une classe App.java , qui est un simple programme «Hello World», dans le dossier src/main/java .

Nous avons également un exemple de classe de test dans src/test/java . Le pom.xml de ce projet ressemblera à ceci:

<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>

Comme vous pouvez le constater, la dépendance junit est fournie par défaut.

5.2. Compiler et empaqueter un projet

La prochaine étape consiste à compiler le projet:

mvn compile

Maven effectuera toutes les phases de cycle de vie nécessaires à la phase de compilation pour créer les sources du projet. Si vous souhaitez exécuter uniquement la phase test , vous pouvez utiliser:

mvn test

Invoquons maintenant le package phase _, qui produira l’archive compilée jar_ :

mvn package

5.3. Exécuter une application

Enfin, nous allons exécuter notre projet Java avec le fichier exec-maven-plugin . Configurons les plugins nécessaires dans le fichier pom.xml :

<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>

Le premier plugin, maven-compiler-plugin , est chargé de compiler le code source à l’aide de Java version 1.8. La exec-maven-plugin recherche le mainClass dans notre projet.

Pour exécuter l’application, nous exécutons la commande suivante:

mvn exec:java

6. Projets multi-modules

Le mécanisme dans Maven qui gère les projets multi-modules (également appelés projets aggregator ) s’appelle Reactor .

Le Reactor collecte tous les modules disponibles pour la construction, trie ensuite les projets dans le bon ordre de construction et les construit un par un.

Voyons comment créer un projet parent multi-module.

6.1. Créer un projet parent

Tout d’abord, nous devons créer un projet parent. Afin de créer un nouveau projet avec le nom parent-project, nous utilisons la commande suivante:

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

Ensuite, nous mettons à jour le type d’emballage dans le fichier pom.xml pour indiquer qu’il s’agit d’un module parent :

<packaging>pom</packaging>

6.2. Créer des projets de sous-modules

Dans l’étape suivante, nous créons des projets de sous-modules à partir du répertoire de 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

Pour vérifier si nous avons correctement créé les sous-modules, examinons le fichier pom.xml de parent-project dans lequel nous devrions voir trois modules:

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

De plus, une section parent sera ajoutée dans le pom.xml de chaque sous-module:

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

6.3. Activer la gestion des dépendances dans le projet parent

La gestion des dépendances est un mécanisme permettant de centraliser les informations de dépendance pour un projet parent multi-module et ses enfants.

Lorsque vous avez un ensemble de projets ou de modules héritant d’un parent commun, vous pouvez placer toutes les informations requises sur les dépendances dans le fichier pom.xml commun. Cela simplifiera les références aux artefacts dans l’enfant __POM __s.

Jetons un coup d’œil à l’exemple pom.xml d’un parent:

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

En déclarant la version spring-core dans le parent, tous les sous-modules qui dépendent de spring-core peuvent déclarer la dépendance en utilisant uniquement groupId et artifactId , et la version sera héritée:

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

De plus, vous pouvez fournir des exclusions pour la gestion des dépendances dans pom.xml du parent, afin que des bibliothèques spécifiques ne soient pas héritées par les modules enfants:

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

Enfin, si un module enfant doit utiliser une version différente d’une dépendance gérée, vous pouvez remplacer la version gérée dans le fichier pom.xml de l’enfant:

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

Veuillez noter que, bien que les modules enfants héritent de leur projet parent, un projet parent ne comporte pas nécessairement de modules qu’il agrège. D’autre part, un projet parent peut également agréger des projets qui n’en héritent pas. **

Pour plus d’informations sur l’héritage et l’agrégation, reportez-vous à la présente documentation].

6.4. Mise à jour des sous-modules et construction d’un projet

Nous pouvons changer le type packaging de chaque sous-module. Par exemple, modifions le packaging du module webapp en WAR en mettant à jour le fichier pom.xml :

<packaging>war</packaging>

Nous pouvons maintenant tester la construction de notre projet en utilisant la commande mvn clean install . La sortie des journaux Maven devrait ressembler à ceci:

----[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. Conclusion

Dans cet article, nous avons présenté certaines des fonctionnalités les plus populaires de l’outil de construction Apache Maven.

Tous les exemples de code sur Baeldung sont construits avec Maven. Vous pouvez donc facilement consulter notre GitHub (site Web du projet) pour voir les différentes configurations Maven.

TOC