L’équipe de développement de Gradle annonce la version 7.0 de l’outil d'automatisation de construction pour le développement de logiciels multilingues. La grande nouveauté et surtout celle la plus attendue dans la version 7.0 de Gradle est la surveillance du système de fichiers par défaut. Gradle 7.0 permet également de rendre les constructions incrémentielles plus rapides, étend la prise en charge de la construction de projets avec Java 16 et ajoute la prise en charge de la construction sur les Mac utilisant les processeurs M1 d’Apple.Cette version introduit également un aperçu des fonctionnalités pour les versions de dépendances centralisées, active les erreurs de validation de construction pour rendre les constructions plus fiables et facilite la création des plugins de convention pour les fichiers de paramètres. De nombreuses fonctionnalités en cours d'incubation ont été promues à la version stable.
Rappelons que Gradle est un outil d'automatisation de la construction pour le développement de logiciels multilingues. Il contrôle le processus de développement lors des tâches de compilation et de packaging jusqu'aux tests, au déploiement et à la publication. Les langages pris en charge sont Java (Kotlin, Groovy, Scala), C/C++, JavaScript.
Gradle s'appuie sur les concepts d’Apache Ant et Apache Maven et introduit un langage spécifique au domaine basé sur Groovy et Kotlin, en contraste avec la configuration de projet basée sur XML utilisée par Maven. Gradle utilise un graphe acyclique dirigé pour déterminer l'ordre dans lequel les tâches peuvent être exécutées, en fournissant une gestion des dépendances.
Gradle a été conçu pour les constructions multiprojets, qui peuvent devenir volumineuses. Il fonctionne sur la base d'une série de tâches de construction qui peuvent être exécutées en série ou en parallèle. Les constructions incrémentielles sont prises en charge en déterminant les parties de l'arbre de construction qui sont déjà à jour ; toute tâche dépendant uniquement de ces parties n'a pas besoin d'être réexécutée.
Le modèle de construction incrémentielle est une méthode de développement logiciel où le produit est conçu, implémenté et testé de manière incrémentielle (un peu plus est ajouté à chaque fois) jusqu'à ce que le produit soit terminé. Le produit est défini comme fini lorsqu'il satisfait à toutes ses exigences (conception, implémentation, test). Ce modèle combine les éléments du modèle de cascade avec la philosophie itérative du prototypage.
Il prend également en charge la mise en cache des composants de construction sur un réseau partagé à l'aide du cache de construction Gradle. Il produit une visualisation de la construction basée sur le Web appelée Gradle Build Scans. Le logiciel est extensible pour de nouvelles fonctionnalités et de nouveaux langages de programmation grâce à un sous-système de plugins. Voici, ci-dessous, quelques nouveautés apportées par la version 7.0 de Gradle.
Amélioration des performances
Cette version contient des améliorations supplémentaires pour le développement incrémental. La partie du processus de développement logiciel où sont apportées de fréquentes petites modifications.
Constructions incrémentales plus rapides
Lors d'une construction incrémentielle, les fichiers d'entrée et de sortie sont vérifiés pour déterminer ce qui doit être reconstruit. Cette fonctionnalité permet généralement de gagner beaucoup de temps ; cependant, elle ajoute une certaine surcharge d'E/S, qui peut être perceptible dans les grands projets lorsque peu de choses ont changé depuis la construction précédente.
La surveillance du système de fichiers a été introduite comme une fonctionnalité optionnelle dans Gradle 6.5 et marquée comme prête pour la production dans Gradle 6.7. Lorsqu'elle est activée, Gradle conserve en mémoire ce qu'il a appris sur le système de fichiers entre les constructions et évite de lire le système de fichiers à chaque construction. Cela réduit considérablement la quantité d'E/S disque nécessaire pour déterminer ce qui a changé depuis la construction précédente. Cette optimisation est maintenant activée par défaut sur toutes les plateformes prises en charge, y compris les versions récentes de Windows, Linux et MacOS.
Modifications incrémentales dans les projets Android
Cette version contient des améliorations de performances pour les changements incrémentaux dans les projets Android, en particulier ceux qui utilisent Jettifier. Par exemple, assembleDebug pour un changement non-ABI sur le projet Android Santa Tracker connait une amélioration de 12 % par rapport à Gradle 6.8.
Santa Tracker : assembleDebug avec changement non-ABI
Ignorer les projets buildSrc vides
Dans les versions antérieures de Gradle, la simple présence d'un répertoire buildSrc suffisait à déclencher l'exécution par Gradle de toutes les tâches buildSrc et à ajouter le buildSrc.jar résultant au chemin des classes buildscript, ce qui entraînait une surcharge inutile des performances ou des pertes de cache.
Avec Gradle 7.0, l’outil ignore maintenant les répertoires buildSrc vides et ne génère un buildSrc.jar que si des fichiers build et/ou des fichiers source sont détectés. Cela présente deux avantages lorsqu'un répertoire buildSrc vide est détecté :
- les tâches :buildSrc: ne seront pas exécutées inutilement ;
- le buildSrc.jar vide ne sera pas ajouté au chemin de la classe buildscript, évitant ainsi les pertes de cache que cela peut provoquer.
Nouvelles fonctionnalités et améliorations de l'ergonomie
Support natif pour Apple Silicon
Les versions précédentes de Gradle pouvaient fonctionner sur les nouveaux Mac équipés de processeurs Apple Silicon avec quelques inconvénients :
- avec un JDK ARM natif, les fonctionnalités de Gradle comme rich console et la surveillance du système de fichiers étaient désactivées ;
- avec un JDK Intel, Gradle s'exécutait avec la moitié du potentiel de sa vitesse grâce à la couche de compatibilité Rosetta2.
Avec la version Gradle 7.0, chaque fonctionnalité est désormais prise en charge par un JDK ARM natif. Si le développeur utilise un nouveau Mac doté d’Apple Silicon, il lui est recommandé d’utiliser Gradle avec un JDK ARM natif pour des performances optimales.
Prise en charge de Java 16
Gradle prend désormais en charge l'exécution et la construction avec Java 16. Dans les versions précédentes de Gradle, l'exécution de Gradle lui-même sur Java 16 entraînait une erreur. Les projets pour la machine virtuelle Java (JVM) pouvaient être construits avec Java 16 en utilisant des piles d'outils avec la compilation incrémentielle désactivée. Depuis Gradle 7.0, l'exécution de Gradle lui-même et la construction de projets JVM avec Java 16 sont entièrement prises en charge.
Versions de dépendances centralisées
Il existe un certain nombre de moyens pour partager les versions des dépendances entre les projets dans les constructions multiprojets. Par exemple, les utilisateurs peuvent déclarer les versions ou les coordonnées des dépendances directement dans les scripts de construction (dans le bloc ext), les fichiers externes (par exemple dependencies.gradle), dans buildSrcor ou même dans des plugins dédiés. Cependant, il n'existait pas de mécanisme standard pour le faire qui combinerait les avantages de chaque approche.
Avec cette version, Gradle introduit les catalogues de versions comme une fonctionnalité expérimentale. Un catalogue de versions permet aux auteurs de constructions de centraliser les coordonnées des dépendances (groupe, artefact, version) de leurs dépendances tierces dans un fichier de configuration conventionnel et de déclarer les dépendances réelles d'une manière fiable. Pour activer cette fonctionnalité expérimentale, la ligne ci-dessous doit être ajoutée dans le fichier settings.gradle(.kts) :
enableFeaturePreview("VERSION_CATALOGS"
Ensuite, il est possible d’utiliser le fichier gradle/libs.versions.toml à la racine du projet pour déclarer le contenu du catalogue :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | [versions]
groovy = "3.0.5"
[libraries]
groovy-core = { module = "org.codehaus.groovy:groovy",
version.ref = "groovy" }
groovy-json = { module = "org.codehaus.groovy:groovy-json",
version.ref = "groovy" }
groovy-nio = { module = "org.codehaus.groovy:groovy-nio",
version.ref = "groovy" }
commons-lang3 = { group = "org.apache.commons",
name = "commons-lang3",
version = { strictly = "[3.8,4.0[", prefer="3.9" } }
[bundles]
groovy = ["groovy-core", "groovy-json", "groovy-nio"] |
| Code : | Sélectionner tout |
1 2 3 4 | dependencies {
implementation libs.bundles.groovy
implementation libs.commons.lang3
} |
En outre, les dépendances qui sont fréquemment utilisées ensemble peuvent être organisées en bundles et déclarées dans les projets pertinents avec une seule ligne de code. Les catalogues peuvent également être partagés entre différentes builds. L’équipe de développement de Gradle met à la disposition des développeurs de plugins, ou pour des cas d'utilisation plus avancés, une API est disponible sur Settings pour déclarer les catalogues de versions.
Mise à jour de Groovy 3
Apache Groovy est un langage de programmation orienté objet, statique et dynamique dont les caractéristiques sont similaires à celles de Python, Ruby et Smalltalk. Il peut être utilisé à la fois comme langage de programmation compilé et comme langage de script pour la plateforme Java. Il est compilé en bytecode pour la machine virtuelle Java et interagit de manière transparente avec d'autres codes et bibliothèques Java.
Groovy 3.0, dispose d'un nouvel analyseur syntaxique qui est beaucoup plus flexible et facile à maintenir que l'analyseur syntaxique des versions précédentes de Groovy. Il s’appelle l’analyseur Parrot parce qu’au début de la création de l’analyseur, l’objectif était que la sortie du nouvel analyseur soit un écho exact de ce que l’ancien analyseur produisait.
Afin de prendre en charge le JDK 16 et de rester à jour avec cette dernière version de Groovy, Gradle a été mis à niveau pour utiliser Groovy 3 dans les scripts de construction Groovy DSL. Groovy 3 est doté d'un nouvel analyseur syntaxique et d'une foule d'autres nouvelles fonctions et capacités qui facilitent l'interopérabilité avec les nouvelles fonctionnalités de Java. Il existe certaines incompatibilités entre Groovy 2 et 3, qui peuvent causer des problèmes lors de la mise à niveau vers Gradle 7.0.
Amélioration de la fiabilité des constructions
Gradle utilise un certain nombre d'optimisations pour s'assurer que les constructions sont exécutées aussi rapidement que possible. Ces optimisations reposent sur le fait que les entrées et les sorties des tâches sont bien définies. Gradle applique une validation aux tâches pour vérifier si elles sont bien définies.
Désactivation des optimisations pour les problèmes de validation
Si une tâche échoue à la validation des entrées/sorties, Gradle l'exécutera désormais sans exécution parallèle des vérifications à jour et du cache de construction.
Validation des dépendances manquantes entre les tâches
L’équipe de développement de Gradle indique qu’une tâche peut consommer la sortie produite par une autre sans déclarer une dépendance de tâche explicite ou inférée. Pour ce cas de figure, Gradle détecte maintenant la dépendance manquante entre le consommateur et le producteur et émet un avertissement dans ce cas.
Amélioration du développement des plugins
Prise en charge des plugins avec plusieurs variantes
Gradle 7 recherche le nouvel attribut org.gradle.plugin.api-version lors de la résolution des plugins. Cela permet aux développeurs de plugins de publier différentes variantes de leurs plugins pour différentes versions de Gradle. Par défaut, les plugins ne publient pas de métadonnées avec cet attribut.
Utilisation des constructions pour les plugins locaux
Le développement de plugins en tant que partie d'une construction composite, pour organiser la logique de construction dans des plugins de convention, n'était jusqu'à présent possible que pour les plugins de projet (plugins appliqués dans des fichiers build.gradle(.kts)). Les plugins de paramètres (plugins appliqués dans les fichiers settings.gradle(.kts)) devaient toujours être développés de manière isolée et publiés dans un dépôt binaire. Cette version introduit une nouvelle construction DSL dans le fichier settings pour inclure les builds de plugins. Les constructions ainsi incluses peuvent fournir à la fois des plugins de projet et de paramètres.
| Code : | Sélectionner tout |
1 2 3 4 5 6 | pluginManagement {
includeBuild("../my-settings-plugin")
}
plugins {
id("my.settings-plugin")
} |
Source : Gradle
Et vous ?
Utilisez-vous un outil d'automatisation de construction ? Lequel ? Que pensez-vous de Gradle ? Quelle amélioration de la version 7.0 de Gradle vous intéresse le plus ?Voir aussi :
Truong annonce la disponibilité Repeat, un outil Java pour l'automatisation des tâches, qui est censé améliorer la productivité des développeurs Entre Java et Kotlin, lequel de ces langages est le meilleur pour le développement d'applications Android ? Le chiffre d'affaires des outils d'automatisation des processus robotisés a augmenté de 63,1% en 2018, pour atteindre les 846 millions de dollars JetBrains Space, un environnement d'équipe intégré qui fournit aux organisations des outils de collaboration, est disponible en EAP