Gradle: build.gradle vs settings.gradle vs gradle.properties

Dans cet article,we’ll look at the different configuration files of a Gradle Java project. Also, we’ll see the details of an actual build.

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

Supposons que nous créons simplement un nouveau projet Java en exécutantgradle init –type java-application. Cela nous laissera avec un nouveau projet avec la structure de répertoires et de fichiers suivante:

On peut considérer le fichierbuild.gradle comme le cœur ou le cerveau du projet. Le fichier résultant de notre exemple ressemble à ceci:

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 blocs de construction fondamentaux de Gradle sont des projets et des tâches. Dans ce cas, puisque le pluginjava est appliqué, toutes les tâches nécessaires à la construction d'un projet Java sont définies implicitement. Certaines de ces tâches sontassemble,check,build,jar,javadoc,clean et bien d'autres.

Ces tâches sont également configurées de telle manière qu'elles décrivent un graphique de dépendances 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 fichierbuild.gradle. La définition la plus simple des tâches ressemble à ceci:

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

Cela ne fera rien d’utile, mais imprimez «Bonjour exemple!» bien sûr.

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

Le fichierbuild.gradle est exécuté sur une instanceProject, avec une instance de projet créée par sous-projet. Les tâches ci-dessus, qui peuvent être définies dans le fichierbuild.gradle, résident dans l'instanceProject dans le cadre d'une collection d'objetsTask. Les tâches elles-mêmes consistent en plusieurs actions sous forme de liste ordonnée.

Dans notre exemple précédent, nous avons ajouté une fermeture Groovy pour imprimer "Hello example!" à la fin de cette liste, en appelant lesdoLast(Closure action) sur notre objethelloTask. Lors de l'exécution deTask, Gradle exécute chacun de sesActions dans l'ordre, en appelant la méthodeAction.execute(T).

Gradle génère également un fichiersettings.gradle:

Le fichiersettings.gradle est également un script Groovy.

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

En outre, il est également possible d’enregistrer le code en tant que partie intégrante de différents cycles de cycle de vie d’une construction.

Le framework requiert l'existence dessettings.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'instanceSettings de la construction, en exécutant le fichier sur lui et en le configurant ainsi. Cela signifie que nous définissons des sous-projets dans notre fichiersettings.gradle comme ceci:

et Gradle appelle la méthodevoid include(String… projectPaths) sur l'instanceSettings lors de la création de la construction.

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

Ce fichier est constitué 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.

Voici des exemples de clés possibles:

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

Un autre cas d'utilisation est la spécification de paramètres JVM comme ceci:

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

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

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