Introduction à Gradle pour Java

Gradle est un outil d'automatisation de build pour la JVM (et au-delà) qui compile votre code, exécute vos tests, gère vos dépendances et conditionne le résultat — le tout piloté par un script de build écrit en Groovy ou en Kotlin. Là où Maven décrit un projet avec du XML fixe, Gradle le décrit avec du code : un script de build qui configure un graphe de tâches. Ce passage à un modèle programmable, combiné à un cache de build incrémental qui saute le travail déjà effectué, explique pourquoi Gradle alimente Android et de nombreux grands projets Java.

Gradle vs. Maven

Les deux outils résolvent le même problème — des builds reproductibles avec des dépendances gérées — mais font des compromis différents. Si vous connaissez déjà Maven, voici la correspondance :

Aucun n'est strictement meilleur. La rigidité de Maven rend les builds prévisibles ; la flexibilité de Gradle rend les builds complexes exprimables. Cette partie enseigne Gradle ; l'introduction à Maven couvre l'autre côté.

Un script de build Java minimal

Un projet Java Gradle consiste en un build.gradle et une structure de répertoires conventionnelle (src/main/java, src/test/java). Appliquer le plugin java intégré est ce qui apprend à Gradle comment compiler, tester et créer un jar :

plugins {
    id 'java'
}

group = 'com.example'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.guava:guava:33.0.0-jre'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

Le DSL Kotlin (build.gradle.kts) exprime la même chose avec des accesseurs typés :

plugins {
    java
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

Les tâches sont l'unité de travail

Tout ce que fait Gradle est une tâche — compileJava, test, jar, build. Les tâches déclarent des dépendances envers d'autres tâches, formant un graphe acyclique dirigé (DAG). Lorsque vous exécutez gradle build, Gradle parcourt ce graphe et exécute chaque prérequis exactement une fois, dans l'ordre. Vous pouvez également définir les vôtres :

task hello {
    doLast {
        println 'Hello from a custom Gradle task'
    }
}

task release {
    dependsOn 'build', 'hello'
}

Le plugin java câble un graphe standard pour vous : classes dépend de compileJava et processResources ; jar dépend de classes ; test dépend de classes et compileTestJava ; et build dépend de jar et test. Demander build exécute donc toutes ces tâches dans l'ordre de dépendance.

Le wrapper et la ligne de commande

Le Gradle Wrapper (gradlew / gradlew.bat) est un script versionné qui télécharge et exécute la version exacte de Gradle attendue par un projet, de sorte que les contributeurs n'ont pas besoin d'avoir Gradle installé globalement :

./gradlew build          # compile, test, and package
./gradlew test           # run tests only
./gradlew clean build    # wipe outputs, then rebuild from scratch
./gradlew tasks          # list available tasks
./gradlew dependencies   # print the resolved dependency tree

Utiliser ./gradlew plutôt qu'un gradle système est la valeur par défaut recommandée — cela rend le build reproductible sur toutes les machines et en CI.

Un exemple concret : un graphe de tâches résolu comme Gradle le fait

Il n'y a pas de Gradle sur l'exécuteur de cette page, donc au lieu d'un vrai build, nous modélisons le moteur central de Gradle en Java pur : un graphe de tâches avec des dépendances, résolu en un ordre d'exécution par un tri topologique — exactement ce que fait Gradle lorsque vous tapez gradle build. La deuxième passe montre comment les tâches à jour sont ignorées, ce qui est l'astuce de build incrémental de Gradle.

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

• Le build déclare 7 tâches, mais vous ne listez jamais un ordre à la main — vous demandez build et le graphe calcule le reste. Cette inversion (déclarer des dépendances, laisser l'outil les ordonner) est au cœur du modèle de tâches de Gradle.
• L'ordre résolu affiche d'abord compileJava et processResources, puis classes, jar, compileTestJava, test, et enfin build. Une tâche ne s'exécute qu'après toutes les tâches dont elle dépend, ce qui explique pourquoi la compilation précède le packaging et les tests précèdent build.
• classes est atteinte par deux chemins (via jar et via test) mais n'apparaît qu'une seule fois dans l'ordre — l'ensemble done garantit que chaque tâche s'exécute une seule fois, tout comme Gradle ne recompile jamais les mêmes sources deux fois dans une même invocation.
• Au deuxième passage, les trois tâches marquées à jour affichent (UP-TO-DATE) et ne sont pas comptées ; seules jar, compileTestJava, test et build affichent (EXEC). C'est le build incrémental de Gradle : les tâches dont les entrées n'ont pas changé sont ignorées.
• La dernière ligne indique 4 of 7 tâches exécutées. Sauter le travail inchangé est exactement la raison pour laquelle un deuxième gradle build est bien plus rapide que le premier, et pourquoi le cache de build compte sur les grands projets.

Ce que couvre le reste de cette partie

Écrire de vrais scripts build.gradle, déclarer et résoudre des dépendances depuis Maven Central, appliquer et configurer des plugins, définir des tâches personnalisées, et utiliser le wrapper en CI. Le chapitre suivant, Construire un projet Java avec Gradle, configure un projet Java Gradle complet depuis un répertoire vide.

Pratique