Gradle: build.gradle contre settings.gradle contre gradle.properties

1. Vue d'ensemble

Dans cet article, nous examinerons les différents fichiers de configuration d'un projet Gradle Java . Nous verrons également les détails d'une version réelle.

Vous pouvez consulter cet article pour une introduction générale à Gradle.

2. build.gradle

Supposons que nous créons simplement un nouveau projet Java en exécutant gradle init –type java-application . Cela nous laissera avec un nouveau projet avec le répertoire et la structure de fichiers suivants:

build.gradle gradle wrapper gradle-wrapper.jar gradle-wrapper.properties gradlew gradlew.bat settings.gradle src main java App.java test java AppTest.java

Nous pouvons considérer le fichier build.gradle comme le cœur ou le cerveau du projet. Le fichier résultant pour notre exemple ressemble à ceci:

plugins { id 'java' id 'application' } mainClassName = 'App' dependencies { compile 'com.google.guava:guava:23.0' testCompile 'junit:junit:4.12' } repositories { jcenter() }

Il se compose de code Groovy, ou plus précisément d'un DSL basé sur Groovy (langage spécifique au domaine) pour décrire les versions. Nous pouvons définir nos dépendances ici et également ajouter des éléments tels que les référentiels Maven utilisés pour la résolution des dépendances.

Les éléments fondamentaux de Gradle sont les projets et les tâches. Dans ce cas, puisque le plugin java est appliqué, toutes les tâches nécessaires à la construction d'un projet Java sont définies implicitement. Certaines de ces tâches sont l' assemblage , la vérification , la construction , le jar , javadoc , le nettoyage et bien d'autres.

Ces tâches sont également configurées de telle manière qu'elles décrivent un graphe de dépendance utile pour un projet Java, ce qui signifie qu'il suffit généralement d'exécuter la tâche de construction et Gradle (et le plugin Java) s'assurera que toutes les tâches nécessaires sont effectuées .

Si nous avons besoin de tâches spécialisées supplémentaires, comme, par exemple, la création d'une image Docker, cela ira également dans le fichier build.gradle . La définition la plus simple possible des tâches ressemble à ceci:

task hello { doLast { println 'Hello Baeldung!' } }

Nous pouvons exécuter une tâche en la spécifiant comme argument de la CLI Gradle comme ceci:

$ gradle -q hello Hello Baeldung!

Cela ne fera rien d'utile, mais imprimez "Hello Baeldung!" bien sûr.

Dans le cas d'une construction multi-projets, nous aurions probablement plusieurs fichiers build.gradle différents , un pour chaque projet.

Le fichier build.gradle est exécuté sur une instance de projet , avec une instance de projet créée par sous-projet. Les tâches ci-dessus, qui peuvent être définies dans le fichier build.gradle , résident dans l' instance Project dans le cadre d'une collection d' objets Task . Les tâches elles-mêmes se composent de plusieurs actions sous la forme d'une liste ordonnée.

Dans notre exemple précédent, nous avons ajouté une fermeture Groovy pour imprimer «Hello Baeldung!» à la fin de cette liste, en appelant le doLast (action de fermeture) sur notre objet Hello Task . Pendant l'exécution de Task , Gradle exécute chacune de ses actions dans l'ordre, en appelant la méthode Action.execute (T) .

3. settings.gradle

Gradle génère également un fichier settings.gradle :

rootProject.name = 'gradle-example'

Le fichier settings.gradle est également un script Groovy.

Contrairement au fichier build.gradle , un seul fichier settings.gradle est exécuté par build Gradle. Nous pouvons l'utiliser pour définir les projets d'une build multi-projets.

En outre, nous pouvons également enregistrer du code dans le cadre de différents hooks de cycle de vie d'une construction.

Le framework nécessite l'existence de settings.gradle dans une build multi-projets, alors qu'il est facultatif pour une build à un seul projet.

Ce fichier est utilisé après la création de l' instance Settings de la construction, en exécutant le fichier contre elle et en la configurant ainsi. Cela signifie que nous définissons des sous-projets dans notre fichier settings.gradle comme ceci:

include 'foo', 'bar'

et Gradle appelle la méthode void include (String… projectPaths) sur l' instance Settings lors de la création de la construction.

4. gradle.properties

Gradle ne crée pas de fichier gradle.properties par défaut. Il peut résider à différents emplacements, par exemple dans le répertoire racine du projet, à l'intérieur de GRADLE_USER_HOME ou à l'emplacement spécifié par l' indicateur de ligne de commande -Dgradle.user.home .

Ce fichier se compose de paires clé-valeur. Nous pouvons l'utiliser pour configurer le comportement du framework lui-même et c'est une alternative à l'utilisation d'indicateurs de ligne de commande pour la configuration.

Des exemples de clés possibles sont:

  • org.gradle.caching = (vrai, faux)
  • org.gradle.daemon = (vrai, faux)
  • org.gradle.parallel = (vrai, faux)
  • org.gradle.logging.level = (silencieux, avertissement, cycle de vie, info, débogage)

En outre, vous pouvez utiliser ce fichier pour ajouter des propriétés directement à l' objet Project , par exemple, la propriété avec son espace de noms: org.gradle.project.property_to_set

Un autre cas d'utilisation spécifie des paramètres JVM comme celui-ci:

org.gradle.jvmargs=-Xmx2g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Veuillez noter qu'il doit lancer un processus JVM pour analyser le fichier gradle.properties . Cela signifie que ces paramètres JVM n'affectent que les processus JVM lancés séparément.

5. La construction en un mot

Nous pouvons résumer le cycle de vie général d'une construction Gradle comme suit, en supposant que nous ne l'exécutons pas en tant que démon:

  • Il se lance en tant que nouveau processus JVM
  • Il analyse le fichier gradle.properties et configure Gradle en conséquence
  • Ensuite, il crée une instance de paramètres pour la construction
  • Ensuite, il évalue le fichier settings.gradle par rapport à l' objet Settings
  • Il crée une hiérarchie de projets , basée sur l' objet Paramètres configuré
  • Enfin, il exécute chaque fichier build.gradle par rapport à son projet

6. Conclusion

Nous avons vu comment différents fichiers de configuration Gradle remplissent divers objectifs de développement. Nous pouvons les utiliser pour configurer une version Gradle ainsi que Gradle lui-même, en fonction des besoins de notre projet.