Pour obtenir un rapport HTML détaillant quels JAR sont utilisés, inutilisés ou en conflits il faut utiliser la commande :

mvn dependency:analyze-report

Pour un rapport directement dans la console c'est par ici.

Merci à @Philou pour l'astuce.

Imaginez, vous êtes en prestation pour une grosse boite et la cellule d'architecture de votre client active tout un tas de plugins Maven sans comprendre comment fonctionnent ces plugins et ni Maven d'une manière générale.

Vous souhaitez donc bloquer l'héritage de la configuration de ces plugins pour ne laisser que les vôtres. Évidemment vous êtes quand même obligé d'hériter du pom parent provenant de la cellule d'architecture pour récupérer quelques properties bien utiles.

Solution :
1) Vous créez un pom abstrait à la racine de votre projet.
2) Dans ce pom vous ajoutez plugin par plugin (ici avec ANT) la désactivation <inherited>false</inherited>:

    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.2</version>
            <inherited>false</inherited>
            ...
          </plugin>
        </plugins>
      </build>
      ...
    </project>

3) Vous créez un second pom abstrait, enfant du premier et duquel héritera tous vos modules.

Et voilà, les modules n'auront plus connaissance des plugins du super-parent.

Je recherchais un moyen de reproduire avec Maven le comportement du implementation de Gradle, j'en parlais ici. Pour ceux qui ne connaîtraient pas l'idée est la suivante :

• Un module B tire en tant que dépendance un module A.
• Si un module C tire à son tour le module B en tant que dépendance, et puisque tout est transitif par défaut dans Maven, alors les classes de C pourront importer les classes de A

Ceci est dangereux car rien ne lie explicitement C à A et il devient impossible de supprimer B en tant que dépendance dans le pom de C.

La solution, déclarer le module A en tant que dépendance optionnelle de B de cette manière :

<dependency>
    <groupId>com.a</groupId>
    <artifactId>module-a</artifactId>
    <version>1.0.0</version>
    <optional>true</optional>
</dependency>

Si C tire B, alors les classes de A ne seront plus visiblent par C dans le classpath mais elles resteront présentent au runtime.

Mes amis.. à vos pom !

Il est très difficile de créer des builds reproductibles en Java via Maven / Gradle & Co. Cette très courte présentation explique bien pourquoi.

Heureusement, il existe un plugin maven permettant de virer les timestamps et les méta-data pour rendre le build reproductible à l'octet près.

Encore une fois, merci à @Philou pour l'info.

Trouver quels jars sont en conflits dans votre build Maven en une ligne : mvn dependency:tree -Dverbose

Bon, je vais résumer ici les différents scopes de Maven parce que l'outil évolue !

compile :
Si A déclare B en scope "compile" alors A tire B ainsi que toutes ses dépendances transitives au moment de la compilation, des tests, du packaging et du run.

test :
Si A déclare B en scope "test" alors A tire B ainsi que toutes ses dépendances transitives mais uniquement au moment de l'exécution des tests.

provided :
Si A déclare B en scope "provided" alors A tire B ainsi que toutes ses dépendances transitives au moment de la compilation, des tests, mais pas du packaging. Aussi, il faudra que B et ses dépendances transitives soient présentes sur l'environnement de run pour que tout fonctionne (typiquement, c'est le cas avec un Tomcat).

system :
Fait la même chose que "provided" mais avec les API native du système d'exploitation (eg. C / Rust, etc). Ce scope est à utiliser principalement lorsque l'on fait du JNI (Java Native Interface).

runtime :
Fait la même chose que "provided" mais pour les micro-services et non les serveurs d'applications. Dit autrement, la dépendance n'est pas accessible au moment de la compilation, donc il n'est pas possible de l'importer explicitement dans votre code, cependant cette dépendance sera incluse dans le package généré et copiée avec vos JAR ; contrairement aux dépendances en scope "provided" qui elles ne sont pas copiées dans le package générée puisqu'elles sont fournies par le serveur d'application.

import :
Si A déclare B en scope "import" alors A inclura la section <dependencyManagement> de B. A noter que ce scope ne peut être affecté à une dépendance que si celle-ci est déclarée dans la section <dependencyManagement> de A.

Je découvrir un type de packaging que Maven est capable de produire : bundle.

Je copie-colle ci-dessous la définition :

This kind of artifact is an OSGi bundle, typically produced using the maven-bundle-plugin which is part of Apache Felix.

The plugin treats all the classes available to your module (the module's own classes, classes provided by dependencies, other classes on the classpath) as one giant set, then lets you select a subset of those classes to bundle into a jar. It also creates the necessary manifest information to make the artifact an OSGi bundle.

So the artifact you're pulling in by using this dependency is a jar, however it's a jar built by choosing a subset from a much larger set of classes, not just the classes that were defined inside the abdera-core module.

If you have a look at the pom for the abdera project you'll see the maven-bundle-plugin configuration which will give you an idea of which classes have been added to the bundle, and which have been held back.

Bref, l'artifact org.mockito:mockito-core:2.28.2 est maintenant de type bundle.

Correspondances des goals Maven en Gradle :

Transformer automatiquement un pom.xml en build.gradle via la commande gradle init.

Les liens vers les fichiers de base de données de vulnérabilités (CVE) du consortium OWASP.

Builder des modules en parallèle sous Maven, je me le note pour reminder (car je l'oublie tout le temps) :

mvn -T 4 clean install        # Builds with 4 threads
mvn -T 1C clean install      # 1 thread per cpu core
mvn -T 1.5C clean install   # 1.5 thread per cpu core