Une introduction rapide à Gradle

Introduction

Le sujet de cette revue sera le système de construction automatique Gradle. En anglais, les systèmes de build sont appelés Build Tools . Pourquoi est-ce même nécessaire ? La création manuelle de projets en Java est un processus plutôt laborieux. Il est nécessaire d'indiquer correctement les bibliothèques et frameworks dont le projet a besoin et dont dépend le projet. Ici vous pouvez lire un excellent article sur Habré : « Travailler avec Java en ligne de commande ». Tôt ou tard, vous commencerez à créer des scripts pour automatiser ce processus. Imaginez maintenant que tous les développeurs du monde entier fassent cela et que chacun réécrive ce que quelqu'un a déjà écrit pour son projet. Et puis sont apparus des systèmes d'assemblage de projets qui automatisent ce processus. De plus, d'une part, ils permettent de monter un projet comme vous le souhaitez, d'autre part, ils mettent à votre disposition des outils plus ou moins standardisés. Une alternative à Gradle est le système de construction automatisé Maven. Ces deux systèmes d'assemblage sont, d'une part, différents, mais d'autre part, ils présentent un certain nombre de similitudes. Il existe du matériel sur ce sujet sur le site Web de Gradle : " Migration de Maven vers Gradle ". Comme indiqué dans ce didacticiel, Gradle et Maven ont une perspective différente sur la façon de créer un projet. Gradle est basé sur un graphique de tâches, qui peuvent dépendre les unes des autres. Les tâches effectuent une sorte de travail. Maven utilise un modèle de certaines phases, auxquelles sont attachés certains « objectifs ». Ces objectifs sont ceux sur lesquels un certain travail est effectué. Cependant, avec ces différentes approches, les deux systèmes de build suivent la même convention et la gestion des dépendances est similaire. Pour commencer à utiliser Gradle, vous devez le télécharger. Dans Google ou Yandex, nous entrons « Gradle Build Tool » et dans les premiers résultats, nous voyons le site officiel : https://gradle.org . Sur la page principale de Gradle, il y a un lien avec le texte "Docs", qui mène à la documentation Gradle . Tout d'abord, nous devons installer (Installer) Gradle, nous sommes donc intéressés par la section " Installation de Gradle " de la documentation. Il existe de nombreuses méthodes d'installation, y compris la méthode « à l'ancienne », c'est-à-dire manuellement (« Installation manuelle »). Selon les instructions, téléchargez un fichier de type « binaire uniquement », qui portera un nom comme gradle-5.1.1-bin.zip. Ensuite, décompressez l'archive et configurez la variable d'environnement PATH selon les instructions. L'essentiel est qu'après avoir exécuté les instructions, la commande gradle -vaffiche la version du Gradle installé. Il peut y avoir un problème : lors de la détermination de l'emplacement, le système ne trouvera pas Gradle là où vous le souhaitez. Par conséquent, sous Windows, vous pouvez faire (sur *nix, il existe des analogues) : for %i in (gradle.bat) do @echo. %~$PATH:i Maintenant, peut-être pouvons-nous commencer à faire connaissance.

Initialiser un projet Gradle

Je voudrais immédiatement noter que Gradle consiste à effectuer des tâches appelées tâches (je les appellerai tâches). Les tâches sont fournies par divers plugins . Je vous conseille d'en savoir plus sur les plugins dans la documentation officielle : " Using Gradle Plugins ". Il existe un ensemble de « Core Plugins » qui sont toujours disponibles lorsque Gradle est installé. Il existe différentes catégories de ces plugins, mais nous nous intéressons à la catégorie « Utilitaire ». Cet ensemble comprend le plugin « Build Init Plugin », qui fournit des tâches pour initialiser un projet Gradle. Nous souhaitons créer un type de projet : " java-application ". Exécutons la tâche Gradle : gradle init --type java-application répondons à quelques questions en cours de route, par exemple, que nous souhaitons utiliser le Groovy DSL (langage de description de tâche standard pour Gradle) et le framework de test JUnit (nous en parlerons dans une autre revue). Après la création, nous recevrons l'ensemble de fichiers suivant : Premièrement, après l'initialisation, nous recevons un wrapper spécial préconfiguré pour notre version de Gradle - il s'agit d'un script spécial. Je vous conseille d'en savoir plus dans la documentation officielle - " The Gradle Wrapper ". Deuxièmement, nous voyons le Gradle Build Script - le fichier build.gradle. Il s'agit du fichier principal, qui décrit les bibliothèques et les frameworks utilisés par notre projet, les plugins qui doivent être connectés au projet et décrit diverses tâches. Je vous conseille d'en savoir plus sur ce fichier dans la documentation officielle : « Build Script Basics ».

Plugins et tâches

Si nous regardons maintenant le contenu du Build Script, nous verrons la section plugins :

plugins {
    id 'java'
    id 'application'
}

Ce sont les mêmes plugins dont nous avons parlé plus tôt. Et s'il existe des plugins, alors certaines tâches s'offrent désormais à nous. Nous pouvons exécuter la commande gradle Tasks et voir ce que nous pouvons maintenant faire avec le projet : Par exemple, en exécutant gradle runnous lancerons la classe principale de notre application java : Comme nous pouvons le voir, la même chose est écrite ci-dessous. 2 actionable tasks: 1 executed, 1 up-to-date Qu'est-ce que cela signifie ? Cela signifie qu'un total de 2 tâches ont été accomplies : De plus, 1 a été effectivement terminée et une n'a pas été exécutée, car... il est à jour, c'est-à-dire que l'état est actuel et que rien n'a été fait. Nous pouvons exécuter ce qu'on appelle "Dry Run" : gradle run -m Exécutons cette commande, nous verrons quelles tâches seront exécutées pour exécuter la tâche d'exécution : Comme nous pouvons le voir, un total de 4 tâches ont été terminées : avant l'exécution de run, les classes de tâches de dépendance ont été exécutées. Les classes elles-mêmes ont 2 dépendances et ont donc également exécuté compileJava et processResources. Lorsque nous effectuons une tâche, nous pouvons l'exécuter tout en affichant un certain niveau de journaux (le niveau de journalisation détermine l'importance des messages que nous voulons voir). Par exemple, nous pouvons faire gradle run -i. Cela nous montrera également des messages d'information tels que :

Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.

Pour plus d'informations sur la connexion à Gradle, je vous conseille de vous référer à la documentation officielle : « Gradle Logging ». Comme nous pouvons le voir, la tâche classes a été ignorée car elle est UP-TO-DATE , c'est-à-dire que l'état est actuel, rien n'a besoin d'être fait, donc aucune action n'a été effectuée. En effet, par défaut, Gradle propose des « vérifications à jour » ou ce qu'on appelle la construction incrémentielle. Vous pouvez en savoir plus sur ce mécanisme dans la documentation Gradle : " Vérifications à jour (AKA Incremental Build) ". Mais ce mécanisme peut être désactivé en exécutant une tâche spécifiant l'indicateur --rerun-tasks. Par exemple, gradle run --rerun-tasks. Ensuite nous verrons : 2 tâches actionnables : 2 exécutées Comme vous pouvez le voir, le nombre de tâches exécutées ne prend en compte que le premier niveau du graphique, c'est-à-dire la tâche d'exécution elle-même et les tâches dont elle dépend directement, c'est-à-dire , Des classes. Les tâches dont dépendent les classes ne sont pas comptées ici (bien qu'elles soient exécutées lors de l'exécution de la tâche classes). Vous devriez également lire sur les tâches :

• « Création de tâches » : décrit comment créer vos propres tâches.
• « Écriture de tâches Gradle personnalisées » : un guide étape par étape pour créer des tâches.
• " Build Script Basics » : notions de base sur les tâches et leur utilisation.

Dépendances

L'une des tâches principales de tout système de build est de gérer les dépendances, c'est-à-dire les bibliothèques/frameworks dont notre projet a besoin. Le système de build doit garantir qu'ils sont disponibles au bon moment et assembler l'artefact final de notre application de la bonne manière. Par défaut, après Gradle Init pour l'application Java, nous verrons le contenu suivant dans le script de construction :

dependencies {
    implementation 'com.google.guava:guava:26.0-jre'
    testImplementation 'junit:junit:4.12'
}

Ici, il est immédiatement clair ce que nous connectons. Mais sans une certaine compréhension, il n’est pas clair ce que sont l’implémentation et le testImplementation ? Ici, nous devons revenir à la documentation de Gradle, car celle-ci est bien écrite. Cela s'appelle " Gestion des configurations de dépendances ". Comme indiqué dans la documentation, chaque dépendance est déclarée avec une certaine portée - la zone dans laquelle cette dépendance sera disponible. Cette étendue est désignée par une configuration, chacune ayant un nom unique. Il est également intéressant de noter que de nombreux plugins Gradle ajoutent des configurations prédéfinies. Pour savoir quelles configurations nous avons nous pouvons exécuter : gradle --console plain dependencies De cette façon, nous verrons une liste de toutes les configurations disponibles et leurs dépendances. Nous pouvons filtrer cette liste pour ne voir que les configurations disponibles elles-mêmes : gradle --console plain dependencies | find " - " Comment savoir quoi utiliser ? Vous devrez faire un peu de lecture ici. Parce que Nous utilisons le plugin « Java », commençons donc par sa documentation et la section « Gestion des dépendances ». Ici, nous voyons qu'il y avait une configuration (alias scope) appelée « compiler » et cela signifiait « dépendance nécessaire lors de la compilation ». Mais ensuite, il a été remplacé (en anglais Superseded) par la mise en œuvre. Vous pouvez en savoir plus sur le remplacement dans la section « Séparation des API et des implémentations ». Il s'avère que cette dépendance sera sur le « chemin de classe de compilation ». Mais parfois, nous souhaitons que notre dépendance soit incluse dans l'artefact final. Pour quoi? Par exemple, nous aurons un fichier jar exécutable, qui devra lui-même contenir tout le nécessaire. Que devons-nous alors faire ? Premièrement, il n'existe pas de support de ce type « prêt à l'emploi » (c'est-à-dire par défaut, sans aucune action supplémentaire). Cela s'explique par le fait que chacun veut collecter les archives à sa manière et Gradle essaie d'être minimaliste. Nous ne pouvons pas non plus utiliser les archives jar sur le chemin de classe (sans manipulations supplémentaires dans le code), car cela ne fonctionne pas de cette façon (voir " Oracle : ajout de classes au chemin de classe du fichier JAR " pour plus de détails). Par conséquent, la plus belle méthode est le code suivant dans le script de construction :

jar {
    manifest {
        attributes 'Main-Class': 'jrgradle.App'
    }
    from configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}

Dans les paramètres de la tâche jar, nous spécifions ce qui sera ajouté au manifeste du fichier jar (voir « Oracle : définition du point d'entrée d'une application »). Et puis nous disons que toutes les dépendances nécessaires à la compilation seront incluses dans le pot. Une alternative consiste à utiliser le « Gradle Shadow Plugin ». Cela peut paraître compliqué, mais d’autres plugins peuvent vous faciliter la vie. Par exemple, lors de la création d'une application Web (par opposition à une application Java courante), nous utiliserons un plugin spécial - " Gradle War Plugin ", qui a un comportement différent et notre vie y sera plus facile (toutes les dépendances nécessaires seront être placé dans un répertoire spécial séparé par le plugin lui-même. Ce travail est réglementé par la manière dont les applications Web doivent être structurées. Mais c'est une histoire complètement différente).

Résultats

Gradle est un excellent choix pour les systèmes de construction de projets. Ceci est confirmé par le fait qu'il est utilisé par les développeurs de projets aussi connus que Spring et Hibernate. Seules les choses les plus élémentaires ont été abordées ci-dessus. Derrière eux se cachent un million de fonctionnalités et d'opportunités qui apparaissent aux développeurs. Gradle prend également en charge la création de projets multi-modules, ce qui n'est pas abordé dans cette revue, mais Gradle lui-même propose un excellent tutoriel : « Création de versions multi-projets ». J'espère que cette revue a également démontré que la documentation de Gradle est écrite à 5+ et que vous pouvez facilement trouver ce dont vous avez besoin si vous savez où chercher. Et cela viendra lorsque vous comprendrez les bases. De plus, Gradle propose d'excellents tutoriels. Je voudrais terminer par une petite liste de ce que vous pouvez voir d'autre en utilisant Gradle :

• Formation Gradle (souvent gratuite).
• Gradle pour Android et Java
• Création d'applications Web Java
• Evgeniy Borissov — Le pouvoir de Gradle (2013)

#Viacheslav