Quand utiliser gradle.properties ou settings.gradle ?

Question

Un build gradle comporte trois fichiers

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

Questions

• Quelles sont les différences entre settings.gradle & gradle.properties ?
• Quand un réglage doit-il être mis en settings.gradle vs. gradle.properties ?

Answer 1

settings.gradle

Le site settings.gradle est un script Groovy, tout comme le fichier build.gradle fichier. Un seul settings.gradle script sera exécuté dans chaque build (par rapport à de multiples build.gradle scripts dans les constructions multi-projets). Le site settings.gradle script sera exécuté avant toute build.gradle script et même avant que le Project sont créées. Par conséquent, il est évalué par rapport à un Settings objet. Avec cet Settings vous pouvez ajouter des sous-projets à votre construction, modifier les paramètres à partir de la ligne de commande ( StartParameter ), et accéder à la Gradle pour enregistrer les gestionnaires du cycle de vie. Par conséquent, il faut utiliser settings.gradle si vos paramètres sont liés à la construction et pas nécessairement au projet ou nécessitent une logique avant les sous-projets possibles sont inclus.

gradle.properties

Le site gradle.properties est un simple fichier Java Properties qui n'acquiert un rôle particulier qu'en étant automatiquement inclus dans la portée de l'option Project (en tant que "propriétés du projet"). Il s'agit d'un simple magasin clé-valeur qui n'autorise que les valeurs de type chaîne (vous devez donc diviser les listes ou les tableaux par vous-même). Vous pouvez mettre gradle.properties à ces emplacements :

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

Answer 2

Un projet multi-modules a 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 submodules peuvent également être situés plus profondément dans des sous-dossiers, mais sans modifier le code dans settings.gradle, leur nom inclura le nom de ces dossiers.

paramètres.gradle

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

rootProject.name = 'project-x'

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

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

build.gradle

Il y a un tel fichier par module, il contient la logique de construction pour ce module.

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

Dans le build.gradle des sous-modules, vous pouvez utiliser compile project(':sub-a') pour qu'un sous-module dépende d'un autre.

gradle.properties

Cette option est facultative, son principal objectif est de fournir des options de démarrage à utiliser pour exécuter gradle lui-même, par ex.

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.properties et peuvent être remplacés par les arguments de la ligne de commande de Gradle. Il est également possible de définir des variables d'environnement pour la construction dans ce fichier en utilisant la commande systemProp. comme préfixe.

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

mon-gradle-stuff/utils.gradle

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

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

d'autres endroits où mettre cela pourraient être src/gradle o src/build/gradle

buildSrc/...

Ce dossier est spécial, il est comme un projet gradle distinct en soi. Il est construit avant toute autre chose, et peut fournir des fonctions à utiliser dans n'importe quel autre fichier gradle. Pour des raisons techniques, la prise en charge par l'IDE des références à ce dossier fonctionne bien mieux que tout autre moyen d'extraire du code commun de plusieurs build.gradle dans un emplacement séparé.

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 tester votre code de construction personnalisé, car vous pouvez avoir des tests unitaires. La structure du dossier source dans buildSrc peut être adapté comme pour tout projet java/groovy/kotlin.