Cycle de vie Maven en Java

Un cycle de vie est le concept central de Maven : construire un projet n'est pas un ensemble arbitraire de tâches, mais une séquence ordonnée de phases bien définies. Lorsque vous tapez mvn package, vous ne nommez pas une seule action — vous demandez à Maven d'exécuter chaque phase jusqu'à package incluse, dans l'ordre. Comprendre cette séquence et la façon dont les objectifs de plugins s'y rattachent, c'est la différence entre exécuter des commandes en aveugle et savoir réellement ce que fait votre build.

Trois cycles de vie, et celui que vous utilisez le plus

Maven est livré avec trois cycles de vie intégrés. Ils sont indépendants — invoquer une phase de l'un ne déclenche pas les autres.

Le cycle de vie default est là où le vrai travail se passe. Le mvn clean install que vous voyez partout est simplement deux cycles de vie en une seule commande : la phase clean du cycle clean, puis la phase install du cycle default.

Les phases du cycle de vie default

Le cycle de vie default comporte 23 phases, mais sept d'entre elles concentrent l'essentiel de chaque build. Elles s'exécutent toujours dans cet ordre :

La règle qui gouverne tout : exécuter une phase exécute cette phase et toutes les phases qui la précèdent. Ainsi, mvn package exécute silencieusement validate, compile et test en premier. Il n'est pas possible de « sauter des étapes » — vous pouvez seulement vous arrêter plus tôt.

mvn validate     # just the sanity checks
mvn compile      # validate -> compile
mvn test         # validate -> compile -> test
mvn package      # ... -> test -> package (produces target/app-1.0.jar)
mvn install      # ... -> package -> verify -> install (now in ~/.m2)
mvn deploy       # the full pipeline, ending with an upload

Les phases sont vides jusqu'à ce que des plugins leur associent des objectifs

Une phase n'est qu'un nom et une position dans la séquence — elle ne fait rien par elle-même. Le travail est effectué par des objectifs de plugins qui sont liés aux phases. Un objectif s'écrit plugin:objectif, par ex. compiler:compile. Pour un projet dont le <packaging> est jar, Maven fournit un ensemble de liaisons par défaut sensé :

Vous pouvez ajouter vos propres liaisons dans pom.xml. Ici, le plugin exec est associé à la phase verify pour qu'il s'exécute automatiquement vers la fin du build :

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <version>3.1.0</version>
      <executions>
        <execution>
          <id>smoke-test</id>
          <phase>verify</phase>
          <goals><goal>java</goal></goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Vous pouvez également invoquer un objectif directement, en dehors de toute phase — mvn compiler:compile n'exécute que cet objectif, en ignorant complètement le cycle de vie. C'est parfois utile, mais au quotidien vous appelez des phases et laissez les liaisons se déclencher.

Exemple concret : simuler le cycle de vie

Maven lui-même n'est pas installé sur ce runner, alors nous modélisons le cycle de vie en Java pur pour rendre ses règles concrètes. Le programme liste les phases par défaut, enregistre le plugin:objectif lié à chacune, puis « exécute » mvn install — en parcourant chaque phase de validate jusqu'à install, et en prouvant que deploy et clean ne sont pas inclus.

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

• La sortie commence à validate et s'arrête à install — six phases pour une seule commande. C'est la règle cumulative en action : mvn install est un raccourci pour exécuter tout le préfixe de la séquence jusqu'à install, jamais la seule phase nommée.
• Chaque phase exécutée a affiché le plugin:objectif qui lui est lié (compile -> compiler:compile, package -> jar:jar, etc.). Les phases sont des emplacements ; les objectifs sont ce qui compile, teste et regroupe réellement. validate a affiché (no goal bound), montrant qu'une phase peut s'exécuter sans rien faire.
• deploy skipped : true confirme que les phases après celle demandée ne s'exécutent jamais. Pour publier dans un dépôt distant, vous devez explicitement demander mvn deploy ; un simple install reste délibérément local.
• clean ran : false prouve que clean appartient à un cycle de vie séparé. Invoquer install ne supprime pas target/, c'est exactement pourquoi mvn clean install les énonce tous les deux — une phase de chaque cycle de vie.
• Les phases se sont exécutées dans l'ordre fixe validate, compile, test, package, verify, install et le programme s'est terminé par BUILD SUCCESS. L'ordre n'est pas négociable ; la promesse de convention-over-configuration de Maven repose sur cette séquence garantie et reproductible.

Commandes courantes en pratique

Une poignée d'invocations couvre presque tout le travail quotidien :

mvn clean              # delete target/
mvn test               # build and run unit tests
mvn package -DskipTests  # build the JAR without running tests
mvn clean install      # fresh build, install to local ~/.m2
mvn clean verify       # CI's favourite: build + unit + integration checks

-DskipTests compile les tests mais ne les exécute pas ; -Dmaven.test.skip=true ignore également leur compilation. Optez pour la première option lorsque les tests sont lents mais doivent tout de même compiler, la seconde uniquement lorsque vous voulez vraiment les mettre de côté.

Prochaines étapes

• Nouveau dans l'outil ? Commencez par l'introduction à Maven, puis lisez comment le POM déclare les plugins et les liaisons.
• Les phases comme compile et package ne réussissent qu'une fois les bibliothèques du projet résolues — voir la gestion des dépendances.
• Vous préférez un modèle de graphe de tâches plutôt qu'une séquence de phases fixe ? Comparez avec l'introduction à Gradle.

Pratique