Gradle 7.4 Propose Des Rapports De Test Agrégés

Gradle a publié la version 7.4 de son outil d'automatisation de build open-source qui permet aux développeurs de créer des tests et des rapports HTML de couverture Jacoco agrégés. La fonctionnalité de catalogue des versions permet la déclaration centralisée des dépendances à utiliser dans les scripts de build. Les services de build partagés permettent la mise en cache de l'état ou des ressources sur plusieurs tâches.

Pour activer ces dernières fonctionnalités, le Gradle Wrapper peut être configuré pour utiliser Gradle 7.4 :

./gradlew wrapper --gradle-version=7.4

Le nouveau plugin test-report-aggregation permet, avec le plugin JVM Test Suite, de combiner les résultats des tests de plusieurs tâches de test, même sur plusieurs projets Gradle dans un seul rapport HTML. Le plugin crée automatiquement un rapport de test agrégé :

plugins {
    id 'test-report-aggregation'
    …
}

dependencies {
    implementation project(':repositories')
    ...
}

application {
    mainClass = 'org.gradle.sample.Main'
}

tasks.named('check') {
    dependsOn tasks.named('testAggregateTestReport', TestReport) 
}

Il est possible de configurer le projet et les suites de tests à utiliser. Après avoir exécuté ./gradlew testAggregateTestReport, le rapport HTML se trouve dans le dossier application/build/reports/tests/unit-tests/aggregated-results.

Le nouveau plugin jacoco-report-aggregation est comparable au plugin test-report-aggregation car il combine le rapports de couverture de code JaCoCo, éventuellement de plusieurs projets, dans un rapport HTML basé sur des suites de tests utilisant le Plug-in JVM Test Suite. Ce plugin crée également automatiquement un rapport de test agrégé :

plugins {
    id 'jacoco-report-aggregation'
    …
}

dependencies {
    implementation project(':repositories')
    ...
}

application {
    mainClass = 'org.gradle.sample.Main'
}

tasks.named('check') {
    dependsOn tasks.named('testCodeCoverageReport', JacocoReport) 
}

Encore une fois, il est possible de configurer quel projet et suites de tests doivent être utilisés. Après avoir exécuté ./gradlew testCodeCoverageReport, le rapport XML et HTML se trouve dans le dossier application/build/reports/jacoco/testCodeCoverageReport

La fonctionnalité catalogues de versions est désormais stable et permet de déclarer les dépendances et leurs versions pour les partager entre les projets. Les catalogues de versions sont définis dans les fichiers settings.gradle ou settings.gradle.kts :

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            library('micronaut-http', 'io.micronaut:micronaut-http-client:3.3.3')
        }
    }
}

Il est possible de déclarer et de réutiliser une version spécifique pour plusieurs composants :

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version('micronaut', '3.3.3'
            library('micronaut-http', 'io.micronaut', 
                'micronaut-http-client').versionRef('micronaut')
	        library('micronaut-runtime', 'io.micronaut',
                'micronaut-runtime').versionRef('micronaut')
        }
    }
}

Le catalogue de versions peut être utilisé dans le fichier build.gradle où libs est un catalogue de versions et micronaut-http et micronaut-runtime sont les noms des dépendances dans le catalogue :

dependencies {
    implementation libs.micronaut-http
    implementation libs.micronaut-runtime
}

Plusieurs dépendances peuvent être combinées dans un bundle :

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version('micronaut', '3.3.3'
            library('micronaut-http', 'io.micronaut', 
                'micronaut-http-client').versionRef('micronaut')
            library('micronaut-runtime', 'io.micronaut',
                'micronaut-runtime').versionRef('micronaut')
            bundle('micronaut', ['micronaut-http', 'micronaut-runtime'])
        }
    }
}

Un bundle simplifie la configuration de build.gradle :

dependencies {
    implementation libs.bundles.micronaut
}

Alternativement, le catalogue peut être stocké sous forme de fichier TOML. Par défaut, le fichier libs.versions.toml sera lu dans un catalogue libs :

[versions]
micronaut = "3.3.3"

[libraries]
micronaut-http = 
    { module = "io.micronaut:micronaut-http-client", version.ref = "micronaut" }
micronaut-runtime = 
    { module = "io.micronaut:micronaut-http-client", version.ref = "micronaut" }

[bundles]
micronaut = ["micronaut-http", "micronaut-runtime"]

[plugins]
…

Le guide de l'utilisateur détaille toutes les options possibles telles que la configuration des plugins et la possibilité d'utiliser plusieurs catalogues.

Cédric Champeau, membre de l'équipe Micronaut et GraalVM chez Oracle Labs, explique comment la fonctionnalité des catalogues de versions peut être utilisée pour gérer les dépendances Micronaut. Micronaut propose déjà un catalogue de versions comme alternative au BOM. Le catalogue de la version Micronaut peut être importé depuis l'emplacement BOM dans Maven central, dans un projet Micronaut sur Gradle 7.4 :

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        create("mn") {
            from("io.micronaut:micronaut-bom:${micronautVersion}")
        }
    }
}

Le nouveau catalogue de versions, appelé mn, peut être utilisé dans le fichier build.gradle. Le DSL Kotlin offre en outre la complétion de code et les notations de dépendance sont type-safe.

Le Build services est une autre nouvelle fonctionnalité stable qui permet de partager l'état ou les ressources entre les tâches. Un build service est un objet qui contient un état tel que la mise en cache ou des instances de base de données. Gradle crée et supprime automatiquement le build service. Le build service est créé en implémentant l'interface BuildService et en définissant éventuellement un ou plusieurs paramètres personnalisés :

public abstract class CacheBuildService implements BuildService<CacheBuildService.Params> {

    interface Params extends BuildServiceParameters {
        Property<Integer> getCustomParameter();
    }

    private final Map<String, Integer> cachingMap = new HashMap();;

    public CacheBuildService() {
        int customerParameter = getParameters().getCustomParameter().get();
        cachingMap.put("James", customerParameter)

        System.out.println(String.format("BuildService: Cache contains value %s", 
            cachingMap.get("James")));
    }

    public Map<String, Integer> getCachingMap() {
        return cachingMap;
    }
}

Ensuite, une tâche est créée qui utilise le CacheBuildService précédemment construit :

public abstract class CacheTask extends DefaultTask {
    @Internal
    abstract Property<CacheBuildService> getCache();

    @TaskAction
    public void useCache() {
        CacheBuildService cache = getCache().get();
        Map<String, Integer> cachingMap = cache.getCachingMap();
        System.out.println(String.format("Task: Cache contains value %s", 
            cachingMap.get("James")));
    }
}

La dernière étape consiste à définir le plug-in, à fournir les paramètres personnalisés facultatifs et à connecter la tâche au CacheBuildServiceProvider :

public class CachePlugin implements Plugin<Project> {
    public void apply(Project project) {
        Provider<CacheBuildService> cacheBuildServiceProvider = 
                project.getGradle().getSharedServices()
                .registerIfAbsent("cache", CacheBuildService.class, spec -> {
            spec.getParameters().getCustomParameter().set(42);
    });

    project.getTasks().register("cache-example", CacheTask.class, task -> {
        task.getCache().set(cacheBuildServiceProvider);
        task.usesService(cacheBuildServiceProvider);
    });
  }
}

L'exécution du plugin avec ./gradlew clean -q cache-example affiche :

BuildService: Cache contains value 42
Task: Cache contains value 42

Plusieurs améliorations facilitant l'utilisation ont été introduites. Le Plugin IntelliJ IDEA marque désormais automatiquement tous les répertoires source utilisés par le Plugin JVM Test Suite en tant que répertoires source de test. La vérification des dépendances de Gradle vérifie les sommes de contrôle des plugins et des dépendances du projet. La génération du fichier de vérification des dépendances est plus stable et le résultat est le même si la configuration de construction et le fichier de vérification ne changent pas.

Les toolchains Java permettent de configurer la version de Java souhaitée via la classe JvmVendorSpec. De nouveaux champs, ADOPTIUM et IBM_SEMERU, ont été ajoutés en tant que fournisseurs en raison de la migration d'AdoptOpenJDK vers Eclipse Adoptium et l'introduction des Runtimes Semeru d'IBM. L'utilisation du champ ADOPTOPENJDK entraînera un avertissement d'obsolescence.

Le cache de configuration a été amélioré pour détecter automatiquement les variables d'environnement, les propriétés système et les propriétés Gradle au lieu d'avoir à utiliser l'API Provider.forUseAtConfigurationTime() désormais obsolète.

Le DSL Kotlin crée désormais des accesseurs de modèle type-safe pour les extensions personnalisées dans les référentiels. Cela permet de créer une configuration plus concise, par exemple en supprimant le withGroovyBuilder :

repositories {
    withGroovyBuilder { // This line is now optional
        "ruby" {
            "gems"()
        }
    }
}

De plus amples détails sur toutes les modifications apportées à la version 7.4 sont documentés dans les release notes.