web-dev-qa-db-fra.com

Quand utiliser gradle.properties vs settings.gradle?

Une construction à trois fichiers

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

Questions

  • Quelles sont les différences entre settings.gradle & gradle.properties?
  • Quand faut-il mettre les réglages dans settings.gradle vs. gradle.properties?
javagradlebuildbuild-system
66
ams

settings.gradle

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

gradle.properties

Le fichier gradle.properties est un simple fichier Java Properties qui n'obtient un rôle spécial que s'il est automatiquement inclus dans la portée de l'objet Project (comme "propriétés du projet"). C'est un simple magasin clé-valeur qui n'autorise que les valeurs de chaîne (vous devez donc scinder vous-même des listes ou des tableaux). Vous pouvez mettre les fichiers gradle.properties à ces emplacements:

  • directement dans le répertoire du projet (pour les valeurs liées au projet)
  • dans le répertoire principal de l'utilisateur .gradle (pour les valeurs liées à l'utilisateur ou à l'environnement)
66
Lukas Körfer

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

(root)
  +- settings.gradle       
  +- build.gradle
  +- gradle.properties     # optional
  +-- buildSrc/            # optional
  |     +- build.gradle    # optional
  |     +-- src/           # optional
  |     +-- test/          # optional
  +-- gradle/              # 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 tels 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 racine d'une arborescence de modules afin que vous ne puissiez avoir qu'un seul fichier settings.gradle 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 y a un tel fichier par module, il contient la logique de construction de ce module.

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

Dans le fichier build.gradle des sous-modules, vous pouvez utiliser compile project(':sub-a') pour créer un sous-module dépendant de l’autre.

gradle.properties

Ceci est facultatif, son objectif principal est de fournir les 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.properties, et remplacées par des arguments de ligne de commande gradle. Il est également possible de définir des variables d’environnement pour la construction de ce fichier en utilisant systemProp. comme préfixe.

N'importe quelle propriété de ce fichier peut être utilisée dans n'importe quel build.gradle. Par conséquent, certains projets placent également des informations de version ou de version de dépendance dans gradle.properties, mais il s'agit probablement d'un abus de ce fichier.

gradle/utils.gradle

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

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

buildSrc/...

Ce dossier est spécial, c'est comme un projet de gradé séparé en lui-même. Il est construit avant de faire quoi que ce soit d’autre et peut fournir une fonction à utiliser dans n’importe quel autre fichier gradle. Pour des raisons techniques, IDE la prise en charge des références à ce dossier fonctionne beaucoup mieux que toute autre méthode d'extraction du code courant de plusieurs fichiers build.gradle dans un emplacement distinct. Vous peut 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.

46
tkruse