Quand utiliser gradle.properties contre settings.gradle?

Une version gradle a trois fichiers

• build.gradle qui définit les scripts de configuration de construction
• gradle.properties
• settings.gradle

Des questions

• Quelles sont les différences entre settings.gradle& gradle.properties?
• Quand faut-il mettre un paramètre settings.gradlevs. gradle.properties?

settings.gradle

Le settings.gradlefichier est un script Groovy, tout comme le build.gradlefichier. Un seul settings.gradlescript sera exécuté dans chaque build (par rapport à plusieurs build.gradlescripts dans les builds multi-projets). Le settings.gradlescript sera exécuté avant tout build.gradlescript et même avant la création des Projectinstances. Par conséquent, il est évalué par rapport à un Settingsobjet. Avec cet Settingsobjet, vous pouvez ajouter des sous-projets à votre build, modifier les paramètres à partir de la ligne de commande ( StartParameter) et accéder à l' Gradleobjet pour enregistrer les gestionnaires de cycle de vie. Par conséquent, utilisez settings.gradlesi vos paramètres sont liés à la construction et pas nécessairement liés au projet ou nécessitent une logique avant que d' éventuels sous-projets soient inclus.

gradle.properties

Le gradle.propertiesfichier est un simple Propertiesfichier Java qui ne gagne un rôle spécial qu'en étant automatiquement inclus dans la portée de l' Projectobjet (en tant que «propriétés du projet»). C'est un simple magasin de valeurs-clés qui n'autorise que les valeurs de chaîne (vous devez donc diviser les listes ou les tableaux par vous-même). Vous pouvez placer des gradle.propertiesfichiers dans ces emplacements:

• directement dans le répertoire du projet (pour les valeurs liées au projet)
• dans le .gradlerépertoire de base de l'utilisateur (pour les valeurs liées à l'utilisateur ou à l'environnement)

Un projet multi-modules comprend un module principal et de nombreux sous-modules. Il a cette disposition:

(root)
  +- settings.gradle       
  +- build.gradle          # optional (commonly present)
  +- gradle.properties     # optional
  +-- buildSrc/            # optional
  |     +- build.gradle    
  |     +-- src/...
  +-- my-gradle-stuff/     # optional
  |     +- utils.gradle    # optional
  +-- sub-a/
  |     +- build.gradle
  |     +- src/
  +-- sub-b/
        +- build.gradle
        +- src/

Les sous-modules peuvent également être situés plus profondément dans les sous-dossiers, mais sans modifier le code dans settings.gradle, leur nom inclura le nom de ces dossiers.

settings.gradle

Le rôle principal de settings.gradle est de définir tous les sous-modules inclus et de marquer la racine du répertoire d'une arborescence de modules, de sorte que vous ne pouvez avoir qu'un seul settings.gradlefichier dans un projet multi-module.

rootProject.name = 'project-x'

include 'sub-a', 'sub-b'

Le fichier de paramètres est également écrit en groovy et la recherche de sous-modules peut être personnalisée.

build.gradle

Il existe un fichier de ce type par module, il contient la logique de construction de ce module.

Dans le build.gradlefichier du module principal , vous pouvez utiliser allprojects {}ou subprojects {}pour définir les paramètres de tous les autres modules.

Dans le build.gradlefichier des sous-modules, vous pouvez utiliser compile project(':sub-a')pour faire dépendre un sous-module de l'autre.

gradle.properties

Ceci est facultatif, son objectif principal est de fournir des options de démarrage à utiliser pour exécuter gradle lui-même, par exemple

org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true

Ces valeurs peuvent être remplacées par un fichier USER_HOME/.gradle/gradle.propertieset remplacées par des arguments de ligne de commande gradle. Il est également possible de définir des variables d'environnement pour la construction dans ce fichier en utilisant systemProp.comme préfixe.

Toute propriété de ce fichier peut être utilisée dans n'importe quel build.gradle, de sorte que certains projets mettent également des informations de version ou de version de dépendance dans gradle.properties , mais c'est probablement un abus de ce fichier.

my-gradle-stuff / utils.gradle

(N'importe quel nom de dossier ou de fichier est possible.) Vous pouvez définir des fichiers de gradle personnalisés supplémentaires pour réutiliser les définitions et les inclure dans d'autres fichiers de gradle via

apply from: "$rootDir/gradle/utils.gradle"

d'autres endroits pour mettre cela pourrait être src/gradleousrc/build/gradle

buildSrc / ...

Ce dossier est spécial, c'est comme un projet gradle séparé en soi. Il est construit avant de faire quoi que ce soit d'autre, et peut fournir une fonction à utiliser dans tout autre fichier gradle. Pour des raisons techniques, la prise en charge par IDE des références à ce dossier fonctionne bien mieux que tout autre moyen d'extraire du code commun de plusieurs build.gradlefichiers vers un emplacement distinct.

Vous pouvez définir une logique de construction personnalisée complexe en java, groovy ou kotlin, au lieu d'écrire et de déployer un plugin. Ceci est également utile pour les tests unitaires de votre code de build personnalisé, car vous pouvez avoir des tests unitaires. La structure du dossier source dans buildSrcpeut être adaptée comme pour tout projet java / groovy / kotlin.