Maven contre Gradle : ce qu'un nouvel arrivant doit savoir pour construire le projet JVM de quelqu'un d'autre

Ce que c'est

Maven : pom.xml déclare des coordonnées (groupId, artifactId, version), des dépendances avec des portées (scopes), et des plugins. Le guide du cycle de vie indique qu'il existe trois cycles de vie intégrés (default, clean, site) ; le cycle de vie par défaut exécute ses phases dans un ordre fixe, et invoquer une phase exécute toutes celles qui la précèdent, si bien que mvn verify valide, compile, teste, empaquette et exécute les vérifications d'intégration. Les objectifs de plugin se rattachent à des phases. Les portées de dépendance (compile par défaut, provided, runtime, test, et import pour les BOM) décident quels classpaths une dépendance atteint. Le guide des dépendances indique que les versions en conflit sont arbitrées par la « définition la plus proche » dans l'arbre, la première déclaration l'emportant à profondeur égale, et que dependencyManagement fixe les versions des dépendances transitives.

Gradle : le guide de base décrit une build en termes de projets et de tâches configurés par des scripts de build (build.gradle en Groovy ou build.gradle.kts en Kotlin) plus un fichier settings.gradle(.kts), les plugins ajoutant des tâches et des conventions. Les dépendances sont déclarées dans des configurations telles que implementation et testImplementation. Lorsque deux chemins demandent des versions différentes d'un module, le chapitre sur la résolution des conflits indique que Gradle sélectionne par défaut la plus élevée des versions demandées. Gradle propose un verrouillage de dépendances optionnel ; Maven n'a pas de fichier de verrouillage intégré, si bien que la répétabilité provient de versions exactes et d'imports de BOM.

Pourquoi c'est important

Un ingénieur habitué à npm, cargo ou pip doit d'abord trouver quel outil et quelle version le dépôt attend. Les deux écosystèmes répondent par un wrapper validé (commit) dans le dépôt : ./gradlew, que la documentation de Gradle appelle la façon recommandée d'exécuter une build, et le ./mvnw optionnel de Maven. Exécuter un outil installé globalement dans une autre version est l'erreur de débutant la plus fréquente, suivie par la supposition de la règle de conflit de l'autre outil.

Comment l'appliquer

• Utiliser le wrapper : ./gradlew build ou ./mvnw verify ; ne recourir à une installation globale que lorsqu'aucun wrapper n'existe.
• Maven : lire pom.xml de haut en bas (parent, properties, dependencyManagement, dependencies, plugins de build) ; mvn dependency:tree montre ce que l'arbitrage a choisi.
• Gradle : lire settings.gradle(.kts) pour la liste des projets, puis le script de build ; ./gradlew tasks et ./gradlew dependencies --configuration runtimeClasspath expliquent la build.
• Sauter les tests de façon visible, et seulement pour l'itération locale : -DskipTests (Maven), -x test (Gradle).
• Builds multi-modules : le réacteur de Maven ordonne les modules selon leurs dépendances à partir du POM racine ; les sous-projets Gradle sont listés dans le fichier settings.

Pièges

La règle de définition la plus proche de Maven peut sélectionner une version plus ancienne que celle dont a besoin une dépendance transitive ; la règle de version la plus élevée de Gradle peut faire entrer une version plus récente que celle avec laquelle un module a été testé. Les scripts de build Gradle sont du code et peuvent faire n'importe quoi. mvn install écrit dans le dépôt local et peut masquer une publication manquante. Les deux mettent en cache les artefacts téléchargés, si bien que les caches d'intégration continue ont besoin d'une clé dérivée des fichiers de build.