Introduction à Apache Maven pour Java

Maven est l'outil standard d'automatisation de build et de gestion des dépendances pour Java. Il transforme un projet en une description déclarative — ce qu'il est, ce dont il dépend, comment il est construit — puis exécute le build à votre place. Au lieu de gérer manuellement les fichiers JAR et les options javac, vous déclarez vos besoins dans un seul fichier et Maven télécharge les dépendances, compile, teste et empaquète votre code selon un cycle de vie prévisible et reproductible.

Le POM : un projet comme donnée

Chaque projet Maven est décrit par un pom.xml (Project Object Model). Il identifie le projet avec trois coordonnées — groupId, artifactId et version (ensemble le « GAV ») — et liste les bibliothèques dont il a besoin. Le même schéma de coordonnées nomme votre projet et chaque dépendance, c'est ainsi que Maven localise les artefacts dans un dépôt.

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.example</groupId>
  <artifactId>shop-app</artifactId>
  <version>1.0.0</version>
  <packaging>jar</packaging>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-web</artifactId>
      <version>6.1.0</version>
    </dependency>
  </dependencies>
</project>

L'élément <packaging> indique à Maven ce qu'il doit produire (jar, war, pom). Le bloc <properties> contient des valeurs réutilisables — ici, la version Java que le compilateur cible. Le POM s'étend pour couvrir les plugins, les profils et l'héritage ; le chapitre Maven POM détaille ces parties.

Les dépendances et le classpath transitif

Vous ne listez que vos dépendances directes. Maven lit le POM de chaque dépendance et intègre tout ce dont elles ont besoin — les dépendances transitives — en construisant automatiquement le classpath complet. Déclarer spring-web importe également spring-core sans que vous ayez à le nommer.

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.17.0</version>
</dependency>

Chaque dépendance possède un scope qui contrôle quand elle est présente dans le classpath. Le scope par défaut, compile, la rend disponible partout ; test la limite au code de test ; provided signifie que le runtime la fournit. Pour les conflits de versions, les exclusions et dependencyManagement, consultez les dépendances Maven.

Scope	Dans le classpath de compilation	Dans le classpath de test	Empaqueté	Utilisation typique
`compile` (défaut)	Oui	Oui	Oui	Bibliothèques ordinaires
`provided`	Oui	Oui	Non	API Servlet, fournie à l'exécution
`runtime`	Non	Oui	Oui	Pilotes JDBC
`test`	Non	Oui	Non	JUnit, Mockito

Le cycle de vie du build

Les builds Maven s'exécutent selon une séquence fixe de phases. Les phases clés du cycle de vie par défaut sont validate, compile, test, package, verify, install et deploy. Exécuter une phase exécute toutes les phases qui la précèdent — mvn package valide, compile et teste d'abord, puis empaquète. On n'appelle jamais les phases dans le désordre.

mvn compile          # compile main sources
mvn test             # compile + run unit tests
mvn package          # compile + test + build the JAR/WAR
mvn install          # package + copy artifact into your local repository
mvn clean package    # delete target/ first, then build fresh

Chaque phase est liée à un ou plusieurs goals fournis par des plugins (par exemple compiler:compile est lié à la phase compile). Les plugins sont là où le travail réel se passe ; le cycle de vie ne fait que l'ordonner. Le chapitre cycle de vie du build Maven passe en revue les trois cycles de vie intégrés et la façon dont les goals se lient aux phases.

Les dépôts

Maven récupère les artefacts depuis des dépôts. Lors d'un build, il cherche d'abord dans votre dépôt local (~/.m2/repository), un cache sur votre machine. En cas d'absence, il télécharge depuis un dépôt distant — par défaut Maven Central — et en conserve une copie localement afin que le prochain build soit rapide sans connexion. Les équipes ajoutent souvent un dépôt privé pour les bibliothèques internes.

project pom.xml  →  local repo (~/.m2)  →  remote repo (Maven Central)
                     (cache hit?)            (download + cache)

Un exemple exécutable

L'environnement d'exécution n'a pas Maven dans son classpath, donc le programme ci-dessous modélise les mécaniques essentielles de Maven avec du code JDK pur : il stocke un POM minimaliste sous forme de map, résout la fermeture de dépendances transitives (en dédupliquant les artefacts partagés) et parcourt le cycle de vie du build en s'arrêtant à la phase demandée. Les formes présentes ici — coordonnées GAV, résolution transitive, phases ordonnées — sont exactement ce que fait le vrai Maven.

java— editable, runs on the server

import java.util.*;

public class Main {
    // A coordinate triple, exactly like Maven's groupId:artifactId:version.
    record Gav(String groupId, String artifactId, String version) {
        @Override public String toString() {
            return groupId + ":" + artifactId + ":" + version;
        }
        String jar() { return artifactId + "-" + version + ".jar"; }
    }

// The project model: each artifact mapped to the dependencies it declares.
    static final Map<String, List<Gav>> pom = new LinkedHashMap<>();

static void declare(Gav a, Gav... deps) { pom.put(a.toString(), List.of(deps)); }

// Build the transitive closure the way Maven resolves a classpath.
    static void resolve(Gav a, Set<String> seen, List<Gav> out) {
        for (Gav d : pom.getOrDefault(a.toString(), List.of())) {
            if (seen.add(d.toString())) {   // de-dupe: each JAR appears once
                out.add(d);
                resolve(d, seen, out);      // then pull in its own dependencies
            }
        }
    }

public static void main(String[] args) {
        Gav app     = new Gav("com.example", "shop-app", "1.0.0");
        Gav web     = new Gav("org.springframework", "spring-web", "6.1.0");
        Gav core    = new Gav("org.springframework", "spring-core", "6.1.0");
        Gav jackson = new Gav("com.fasterxml.jackson.core", "jackson-databind", "2.17.0");
        Gav annot   = new Gav("com.fasterxml.jackson.core", "jackson-annotations", "2.17.0");

declare(app, web, jackson);   // our project's direct dependencies
        declare(web, core);           // spring-web transitively needs spring-core
        declare(jackson, annot);      // jackson-databind needs jackson-annotations
        declare(core);
        declare(annot);

System.out.println("Project coordinates: " + app);
        System.out.println("Direct dependencies:");
        for (Gav d : pom.get(app.toString())) System.out.println("  - " + d);

List<Gav> classpath = new ArrayList<>();
        resolve(app, new HashSet<>(), classpath);
        System.out.println("Resolved classpath has " + classpath.size() + " JARs:");
        for (Gav g : classpath) System.out.println("  - " + g.jar());

List<String> phases = List.of("validate", "compile", "test", "package", "install");
        String goal = "package";
        System.out.println("Executing: mvn " + goal);
        for (String p : phases) {
            System.out.println("  phase " + p + " -> OK");
            if (p.equals(goal)) break;   // stop once the requested phase is reached
        }
        System.out.println("BUILD SUCCESS");
    }
}

Ce qu'il faut retenir de l'exécution :

Le projet et chaque dépendance sont nommés par le même triple GAV, ce qui explique pourquoi Project coordinates: com.example:shop-app:1.0.0 se lit exactement comme une ligne de dépendance.
Seules deux dépendances sont déclarées, mais le classpath résolu contient quatre JARs — spring-core et jackson-annotations ont été intégrés transitivement, exactement comme Maven le fait.
L'ensemble seen garantit que chaque artefact n'apparaît qu'une seule fois ; c'est la déduplication de Maven qui empêche une bibliothèque partagée d'atterrir deux fois dans le classpath.
Executing: mvn package exécute validate, compile et test avant package puis s'arrête — exécuter une phase exécute toujours toutes les phases précédentes dans l'ordre.
Le build s'arrête à package et n'atteint jamais install, reflétant la façon dont le goal demandé limite jusqu'où le cycle de vie progresse.

Quand recourir à Maven

Maven excelle sur les projets Java et JVM conventionnels : ses valeurs par défaut « convention plutôt que configuration » (sources dans src/main/java, tests dans src/test/java, sortie dans target/) signifient qu'un nouveau contributeur peut builder n'importe quel projet Maven de la même façon. Son XML déclaratif est facile à lire et à comparer, et le support des IDE est mature. La contrepartie est la verbosité et la flexibilité limitée pour les builds inhabituels. Lorsque vous avez besoin de builds scriptés et très personnalisés, Gradle est l'alternative courante — il utilise un script de build programmable plutôt que du XML déclaratif mais couvre les mêmes aspects : coordonnées GAV, dépendances transitives et un graphe de tâches (plutôt que de phases).

Prochaines étapes

Maven POM — la structure complète de pom.xml, incluant les plugins et l'héritage.
Dépendances Maven — les scopes, les exclusions et la résolution des conflits de versions en profondeur.
Cycle de vie du build Maven — chaque phase, les trois cycles de vie et la liaison des goals.
Introduction à Gradle — l'alternative basée sur les scripts à Maven.

Pratique

Dans Maven, que se passe-t-il quand vous exécutez 'mvn package' ?

Maven exécute toutes les phases du cycle de vie précédentes (validate, compile, test) puis empaquète l'artefactMaven exécute uniquement la phase package et ignore la compilation et les testsMaven déploie l'artefact vers un dépôt distantMaven télécharge le JDK avant de builder