Maven Build Tool : installer, lifecycle et builds Java pour DevOps

À la fin de ce tutoriel, vous aurez Apache Maven 3.9.x installé sur Ubuntu 24.04, un projet généré via archetype, un pom.xml lisible, et les commandes mvn clean package / dependency:tree maîtrisées — prêtes pour un pipeline Jenkins ou une image Docker.

Niveau : Débutant · Temps estimé : 45–60 min · Versions testées : Maven 3.9.9 · JDK 17+ · Ubuntu 24.04 LTS · Dernière vérification : 2026-09-13

Prérequis

Avant d’installer Maven Build Tool, vérifiez votre environnement. Vous avez besoin d’Ubuntu 24.04 LTS (ou équivalent Debian) avec au moins 4 Go de RAM et 10 Go d’espace disque libre. Le JDK 17 ou supérieur doit être présent : Maven compile et exécute les plugins sur la JVM.

java -version

Si Java manque, installez OpenJDK 17 puis revalidez :

sudo apt update
sudo apt install -y openjdk-17-jdk
java -version

Autres prérequis utiles pour un parcours DevOps :

• Accès sudo et connexion Internet (téléchargement d’artefacts Maven Central)
• Bases Git pour versionner le pom.xml
• Notion de CI (vous brancherez ensuite sur Jenkins ou Azure Pipelines)

Coût estimé : 0 € en local (pas de cloud requis pour ce lab).

Ce que nous allons construire

Poste DevOps prêt pour builds Java
  ├── JDK 17+ vérifié
  ├── Apache Maven 3.9.x sous /opt + PATH
  ├── Projet archetype quickstart (src/main/java, src/test/java)
  ├── pom.xml : GAV, compiler release 17, JUnit
  ├── Lifecycle : validate → compile → test → package → install
  └── Commandes CI : clean package, -DskipTests, dependency:tree, Wrapper

Objectif : des builds reproductibles (mêmes entrées → même artefact JAR/WAR), compréhensibles pour un agent CI, sans magie locale cachée dans ~/.m2 non documentée.

Étape 1 — Pourquoi Maven en DevOps ?

Maven Build Tool standardise trois choses que les équipes Java perdent souvent dans des scripts ad hoc : la structure de projet, la résolution de dépendances, et le lifecycle (phases ordonnées). Le fichier pom.xml (Project Object Model) est la source de vérité : coordinates GAV (groupId, artifactId, version), dépendances, plugins, profils.

En CI/CD, Maven apporte :

• Un artefact prévisible (target/*.jar) pour Docker / registry
• Des tests unitaires (Surefire) et d’intégration (Failsafe) branchés sur des phases
• Un dépôt local ~/.m2/repository cacheable sur les agents
• Le Maven Wrapper (mvnw) pour figer la version Maven dans le dépôt Git

Sans standard, chaque laptop « build autrement » que Jenkins : exactement le problème que Maven et le Wrapper résolvent.

Étape 2 — Installer Maven 3.9.x (méthode recommandée)

Sur Ubuntu, le paquet maven via apt fonctionne, mais la version peut être en retard. Pour aligner lab et CI sur 3.9.9 (canal Apache courant en 2026), installez le binaire officiel sous /opt.

cd /tmp
curl -fsSL -o apache-maven-3.9.9-bin.tar.gz \
  https://archive.apache.org/dist/maven/maven-3/3.9.9/binaries/apache-maven-3.9.9-bin.tar.gz
sudo tar -xzf apache-maven-3.9.9-bin.tar.gz -C /opt
sudo ln -sfn /opt/apache-maven-3.9.9 /opt/maven

Ajoutez Maven au PATH (session courante + profil) :

echo 'export PATH=/opt/maven/bin:$PATH' | sudo tee /etc/profile.d/maven.sh
source /etc/profile.d/maven.sh
mvn -v

La sortie affiche la version Maven, le chemin Java (Java home) et le runtime. C’est votre check « agent prêt ».

Alternative apt (rapide)

sudo apt update
sudo apt install -y maven
mvn -v

Utilisez apt pour un lab express ; préférez le tarball /opt (ou SDKMAN) quand la même version doit tourner sur tous les agents Jenkins.

Note lab : d’anciennes recettes « dépôt apt » pointant vers l’archive binaire Apache sont incorrectes. Ici on extrait le tarball officiel ou on utilise le paquet distro — pas un faux sources.list sur des binaires.

Étape 3 — Lifecycle Maven : phases utiles

Maven organise le build en phases cumulatives. Demander une phase exécute toutes les phases précédentes du même lifecycle.

Phase	Rôle DevOps
validate	Contrôle le POM et la structure
compile	Compile src/main/java
test	Tests unitaires (Surefire)
package	Produit JAR/WAR dans target/
verify	Contrôles post-package (Failsafe, checks)
install	Installe l’artefact dans ~/.m2/repository
deploy	Publie vers un dépôt distant (Nexus/Artifactory)

Commandes de base :

mvn validate
mvn compile
mvn test
mvn package
mvn install

En CI, le couple le plus courant est mvn clean verify ou mvn clean package : clean efface target/ pour éviter un artefact stale.

Étape 4 — Créer un projet minimal (archetype)

Générez un squelette standard avec l’archetype quickstart :

mvn archetype:generate \
  -DgroupId=com.example \
  -DartifactId=myapp \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DinteractiveMode=false
cd myapp

Vous obtenez src/main/java, src/test/java et un pom.xml. Exemple de POM moderne (Java 17, JUnit 4.13.2 côté tests — vous pourrez migrer vers JUnit 5 ensuite) :

<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>com.example</groupId>
    <artifactId>myapp</artifactId>
    <version>1.0-SNAPSHOT</version>
    <properties>
        <maven.compiler.release>17</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

maven.compiler.release remplace avantageusement le duo source/target : vous ciblez clairement le niveau de bytecode.

Buildez une première fois :

mvn clean package
ls target/*.jar

Étape 5 — Commandes Maven indispensables en CI

Nettoyage + install local (utile pour multi-modules) :

mvn clean install

Packaging rapide sans tests (à réserver aux étapes où les tests tournent ailleurs — jamais comme seule qualité) :

mvn package -DskipTests

POM effectif (après parents / BOM / profils) :

mvn help:effective-pom

Arbre de dépendances (conflits, versions transitives) :

mvn dependency:tree

Chaque commande produit des logs de plugins : en cas d’échec, Maven arrête la phase et n’enchaîne pas les suivantes.

Maven Wrapper (recommandé sur Git)

Pour que laptop et Jenkins utilisent la même version Maven :

mvn -N wrapper:wrapper -Dmaven=3.9.9
./mvnw -v
./mvnw clean package

Commitez mvnw, mvnw.cmd et .mvn/wrapper/. En pipeline, appelez ./mvnw plutôt que mvn système.

Étape 6 — Dépôts, scopes et ~/.m2

Le dépôt local par défaut est ~/.m2/repository : artefacts téléchargés + ceux installés via mvn install. En CI, isolez éventuellement le repo (-Dmaven.repo.local=...) pour éviter la pollution entre jobs.

Scopes fréquents : compile (défaut), provided (servlet API, etc.), runtime, test (JUnit). Mal placer un scope fausse le classpath de prod ou grossit inutilement l’image Docker.

Mirrors / credentials d’entreprise vivent dans ~/.m2/settings.xml (ou -s chemin/settings.xml). Ne committez jamais de secrets dans le POM.

Étape 7 — Brancher Maven sur Jenkins et Docker

Sur Jenkins, un stage typique :

stage('Build') {
  steps {
    sh './mvnw clean package'
  }
}

Puis construisez une image légère qui copie uniquement le JAR (target/myapp-*.jar) — voir le parcours Docker et, plus loin, le déploiement Kubernetes. Pour l’IaC autour des agents, le hub DevOps et le Capstone Project ferment la boucle.

Profils Maven (-Pdev, -Pprod) permettent d’activer plugins ou propriétés par environnement sans dupliquer le POM.

Étape 8 — SNAPSHOT vs RELEASE et qualité de build

En DevOps, la distinction SNAPSHOT / RELEASE évite de « écraser » silencieusement un artefact de prod. Une version 1.0-SNAPSHOT peut être republiee ; une 1.0.0 est immuable une fois déployée sur le dépôt d’entreprise. Les pipelines de release (tags Git, notes de version) doivent produire des RELEASE, tandis que les branches de feature restent en SNAPSHOT.

Pour la qualité, séparez clairement :

• Surefire : tests unitaires rapides liés à la phase test
• Failsafe : tests d’intégration liés à verify / integration-test

Exemple minimal Surefire (souvent déjà géré par le super POM ; épingler la version en pluginManagement reste une bonne pratique d’équipe) :

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.2.5</version>
</plugin>

Sur un agent Jenkins partagé, exportez MAVEN_OPTS pour la mémoire et activez un cache du dépôt local entre builds du même job — sans partager un ~/.m2 corrompu entre projets hostiles.

Étape 9 — Lab guidé : du clone au JAR en cinq minutes

Scénario réel que vous rejouerez sur chaque nouvelle VM :

1. Vérifier java -version (17+) et mvn -v (3.9.x)
2. Générer ou cloner le projet ; s’assurer que pom.xml est suivi par Git
3. Lancer ./mvnw clean package (ou mvn clean package si Wrapper absent)
4. Contrôler target/*.jar et le code de sortie 0
5. Archiver le JAR comme artefact CI, puis docker build dans un stage suivant

Si l’étape 3 échoue sur une dépendance, exécutez mvn dependency:tree -Dverbose et cherchez les versions en conflit (souvent deux libs qui tirent des Guava / Jackson différents). La correction propre passe par dependencyManagement dans un POM parent, pas par des exclusions sauvages multipliées partout.

Petit checklist avant merge :

• Le Wrapper est commité si l’équipe l’a adopté
• Aucun mot de passe dans settings.xml versionné
• maven.compiler.release aligné sur le JDK de l’agent
• Les tests critiques ne sont pas masqués en permanence par -DskipTests

Étape 10 — Multi-modules et profils (aperçu opérationnel)

Dès qu’une appli se découpe en api, core, ops, un reactor multi-modules devient naturel : un POM parent packaging=pom liste les modules, centralise les versions et les plugins. Un seul mvn clean verify à la racine construit tout dans le bon ordre.

Les profils activent des comportements par environnement (-Pprod pour un plugin de checksum, un filtre de ressources, ou un repo interne). Gardez les profils documentés dans le README du dépôt : un profil « magique » oublié est une source classique de « ça marche chez moi ».

Pour l’observabilité du build, lisez les temps par plugin dans les logs CI : un dependency:resolve lent signale souvent un mirror distant ou l’absence de cache. Sur Hostinger lab ou VM cloud, préférez un agent dédié Java plutôt que de réinstaller Maven à chaque job.

Étape 11 — settings.xml et miroirs (agents CI)

Le fichier settings.xml (souvent sous ~/.m2/) complète le POM : miroirs Maven Central, serveurs Nexus/Artifactory, proxies. En CI, préférez mvn -s settings-ci.xml pour isoler les secrets du home Jenkins. Ne committez jamais de mots de passe ; injectez-les via le credentials store. Documentez le mirror d’entreprise dans le README du pipeline. Après un échec réseau, relancez mvn dependency:resolve avant de suspecter le POM. Objectif : la même résolution de dépendances sur le laptop et sur l’agent, puis un JAR stable dans target/ prêt pour Docker.

Erreurs fréquentes

Symptôme	Cause	Correction
JAVA_HOME / mvn introuvable	PATH ou JDK manquant	Installer JDK 17+, exporter PATH /opt/maven/bin
Échec de compilation	Erreurs Java ou release incohérent	Lire target/ / logs compiler ; aligner maven.compiler.release
Dépendance non résolue	Réseau, mirror, version absente	dependency:tree, vérifier settings.xml et Maven Central
Conflit de plugins	Versions implicites divergentes	Épingler les plugins dans pluginManagement
OutOfMemoryError	Heap trop bas sur gros multi-module	export MAVEN_OPTS="-Xmx2g" (ajuster selon agent)
Vert en local, rouge en CI	Version Maven / JDK différente	Maven Wrapper + même JDK sur l’agent

Quiz (3 questions)

1. Que fait mvn package en plus de compile ?
– A. Uniquement télécharger Docker
– B. Exécuter les phases jusqu’à package (donc aussi test, sauf skip) et produire l’artefact dans target/
– C. Publier forcément sur Maven Central

2. Où se trouve le dépôt local par défaut ?
– A. /var/lib/maven
– B. ~/.m2/repository
– C. /opt/maven/repo uniquement

3. Pourquoi recommander ./mvnw en CI ?
– A. Pour désactiver Git
– B. Pour figer la version Maven avec le dépôt et éviter le drift laptop/agent
– C. Pour remplacer le JDK

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

• Multi-modules (reactor) et dependencyManagement / BOM
• Profils dev / staging / prod
• Surefire vs Failsafe (unit vs integration)
• Plugin fabric8 / Jib pour images sans Docker daemon
• Enchaîner avec Ansible pour provisionner les agents, puis Jenkins pour le pipeline

Maillage série DevOps

Aussi	Jenkins · Docker · Kubernetes · Git · Ansible · Capstone Project
Hub	Parcours CI/CD & Jenkins (leçon Maven Build Tool)