Maven Avancé : offline, debug, tree, list, Reactor

Maven : Quelques Commandes Utiles

Forcing updates

Working offline is sometimes interesting, but forcing updates can be useful to retrieve the latest version of a snapshot artifacts developed by one of your teammates. The --update-snapshots options (or -U) forces maven to check all snapshot dependencies and retrieve latest versions:

mvn --update-snapshots clean install or mvn -U clean install



Thanks to this option, you’re sure to build the project against the latest available version of all your snapshot dependencies. If not used, the dependencies are checked once a day (default behavior).

Specific local repository

The maven.repo.local variable allows configuring the local repository location of Maven:

mvn clean install –Dmaven.repo.local=~/tmp/tmp-repo



This creates a complete new local repository at the specified location.

Offline Mode

Maven often takes a lot of time to check the potential updates of dependencies and plugins. But sometimes, you want to skip this process, either because you don’t have an Internet connection or because you know that you can safely ignore them.

Before being able to run maven in offline mode, be sure you have compiled everything at least one time online. Maven retrieves all the dependencies in your local repository. Then, the offline mode just reuses the latest retrieved artifacts. Enabling the offline mode is quite simple:

mvn –-offline clean install or mvn  -o clean install

Debug maven

mvn -X

This command is used to start the maven goals in debug mode and gives logging information. This command gives more information like what artifact is failing for what reason. This command can be used when you are not getting any clue for your maven project execution failure.

Maven Dependencies information

mvn help:effective-pom

Shows the logical contents of a pom.xml, including contents inherited from the parent pom.xml, up to and including the Maven super POM.

mvn dependency:tree

Shows all dependencies (including transitive dependencies) of your project. This is very helpful for debugging dependency version issues.

mvn dependency:list

There is another Maven dependency plugin goal: dependency:list.  It displays the same project’s dependencies in a flat, alphabetically-sorted list

mvn dependency:sources

Downloads all project sources separate from IDE project creation.  Execute from root of parent project, then have your IDE synch up sources.

Maven Reactor

Dans un projet multi-module, Maven offre des options permettant de contrôler le build de modules avec leurs dépendances. En effet, il existe des options qui vous permettent de manipuler la façon dont Maven va construire vos projets multi-module. C'est grâce au plugin maven-reactor-plugin qui a été redescendu au coeur de Maven.  Pour illustrer mes propos, je prends l’exemple d’un projet multi-module (Root) contenant :

1.    Le module common partagé par tous les autres modules. Ce dernier ne dépend d’aucun autre module.
2.   Le module core contenant 2 sous modules : dea et domain qui dépendent eux aussi du module common
3.   Le module service dépend du module dea.

Si on résume :

-          Module service è dea

-          Module dea è common

-          Module domain è common

-          Module common indépendant

Pour connaitre l’ordre de construction de module et le graphe de dépendance, il suffit de taper la commande : mvn install

Il faut remarquer ici qu’avant la construction d’un module, toutes ses dépendances sont préalablement construites : construction du module common, ensuite core/dea puis core/domain et enfin service…

Resuming the Build with --resume-from

Qui n’a pas fait un commit (par erreur ou pas !) d’une classe qui ne compile pas ou qui fait échouer les tests ? Cela fait automatiquement échouer la construction du module concerné. Une option très utile pour commencer la construction du projet à partir d’un module (donc ignorer le module fautif). Imaginons juste qu’une erreur survient dans le module core/domain (erreur de compilation ou de test qui ne passe plus, etc.). Lorsque vous lancez la commande mvn install vous aurez :

La construction du module core/domain a échoué. Vous remarquez aussi que la construction des autres modules est ignorée (SKIPPED). En effet, lorsqu’une erreur survient dans un module (domain ici), la construction s’arrête et les modules restants sont ignorés (dea et service). 

Solution 1 : option  --resume-from ou –rf

Nous corrigeons le module domain sans changer common ; nous savons que common est bon et que donc il n'est pas nécessaire de le reconstruire ou de le tester. Nous pouvons alors utiliser l'argument resume-from (-rf) ainsi :

mvn install –rf [–resume-from] core/domain

Le module passé en paramètre de l’option -rf est identifié à partir de son chemin relatif ou de son artifactId.

Ainsi, common ne sera pas reconstruit et le build reprendra là où nous l'avions laissé dans domian. Si domain est construit avec succès, Maven poursuivra et construira les autres modules.

Solution 2 : --fail-at-end (--fae)

Cette solution consiste à ignorer la construction du module. La construction du projet continue malgré l’erreur survenue dans le module domain.

Tous les modules sont construits excepté domain.

Maven pl(--projects)

Une option qui vous permet de choisir spécifiquement les modules du projet à construire. La liste de modules est séparée par des virgules. Pour identifier chaque module, vous pouvez soit utiliser son chemin relatif par rapport à la racine du projet soit son artifactId.

Seuls les deux modules (domain et service) sont construits, ce qui nous évitera d'avoir à exécuter Maven séparément dans chaque répertoire.

Maven --also-make

Une option qui s’utilise conjointement avec l’option -pl. En plus de construire les modules demandés par l’option -pl, Maven va également construire toutes les dépendances de chaque module. Par exemple, mvn install –pl dea –am va d’abord construire le module common puis celui de core/dea comme illustré sur cette image.

Lorsque nous utilisons --also-make, Maven va examiner la liste de modules passés en paramètre (ici, uniquement core/dea) et va descendre dans l'arbre des dépendances à la recherche des modules qu'il va devoir construire. Dans ce cas, il va automatiquement construire common (car core/dea dépend du module common), mais sans construire core/domain ni service.

Avec –pl service, common est construit (une dépendance de dea) puis core/dea (une dépendance de service) et on termine par la construction du module service.

Si vous avez bien compris, le module common ne dépend d’aucun module :

Maven --also-make-dependents

Comme pour (-am), cette option s’utilise conjointement à l’option -pl. En plus de construire les modules demandés par l’option -pl, Maven va construire tous les modules qui dépendent de ces derniers. Si vous exécutez la commande mvn install –pl core/dea –amd, Maven construit d’abord le module core/dea puis service (qui dépend du module dea). En plus la construction du module core/dea, Maven a construit tous les modules qui dépendent du module core/dea (dans notre exemple, il y a que le module service qui dépend du core/dea)

La commande mvn clean install –pl common –amd permet de construire tous les modules : on commence par la  construction du module common. 

• Quels sont les modules qui dépendent du common ? core/domain et core/dea, il faudra donc les construire. 
• Ensuite, quels sont les modules qui dépendent des modules core/dea ou core/domain ? service dépend du module core/dea donc il faut le construire….