Lors de l'utilisation de gradle.propriétés vs paramètres.gradle?

Un build gradle a trois fichiers

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

Questions

  • Quelles sont les différences entre settings.gradle & gradle.properties?
  • Quand un des paramètres de mettre en settings.gradle vs
    gradle.properties?
InformationsquelleAutor ams | 2017-07-29
  1. 65

    settings.gradle

    La settings.gradle fichier est un script Groovy, tout comme le build.gradle fichier. Un seul settings.gradle script sera exécuté à chaque build (en comparaison à de multiples build.gradle scripts multi-projet de construit). Le settings.gradle script sera exécuté avant toute build.gradle script et avant même la Projet des instances sont créées. Par conséquent, il est évalué par rapport à une Paramètres objet. Avec cette Settings objet vous pouvez ajouter des sous-projets de votre construction, de modifier les paramètres de la ligne de commande (StartParameter), et l'accès à la Gradle objet au registre du cycle de vie des gestionnaires. En conséquence, l'utilisation settings.gradle si vos paramètres sont construction liés, et pas nécessairement liés à un projet ou un besoin de logique avant possible des sous-projets sont inclus.

    gradle.properties

    La gradle.properties fichier est un simple Java Propriétés fichier seulement les gains d'un rôle particulier par le fait d'être automatiquement inclus dans le champ d'application de la Project objet (comme les soi-disant projet "propriétés"). C'est une simple clé-valeur en magasin qui permet uniquement de la chaîne de valeurs (si vous avez besoin de partager des listes ou des tableaux par vous-même). Vous pouvez mettre gradle.properties fichiers à ces endroits:

    • directement dans le répertoire du projet (pour les projets liés à des valeurs)
    • dans l'accueil de l'utilisateur .gradle répertoire (par l'utilisateur ou l'environnement liés à des valeurs)
    InformationsquelleAutor Lukas Körfer
  2. 46

    Un multi-projet de module a un module principal et de nombreux submodules. Il a cette mise en page:

    (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/

    submodules peut également être situé plus profondément dans les sous-dossiers, mais sans modification de code dans les paramètres.gradle, de leur nom inclure le nom de ces dossiers.

    paramètres.gradle

    Le rôle principal de réglages.gradle est de définir tous inclus submodules et pour marquer le répertoire racine d'un arbre de modules, de sorte que vous ne pouvez avoir qu'un settings.gradle de fichiers dans un environnement multi-projet de module.

    rootProject.name = 'project-x'

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

    Le fichier de paramètres est également écrit en groovy, et le sous-module de recherche peuvent être personnalisés.

    construire.gradle

    Il ya un tel fichier par module, il contient de la construction logique de ce module.

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

    Dans le build.gradle fichier des submodules, vous pouvez utiliser compile project(':sub-a') de faire un sous-module dépend de l'autre.

    gradle.propriétés

    Cela est facultatif, son but principal est de fournir des options de démarrage à utiliser pour l'exécution de 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é par des gradle arguments de ligne de commande. Il est également possible de définir des variables d'environnement pour la construction de ce fichier à l'aide de systemProp. comme préfixe.

    Des biens dans ce fichier peut être utilisé en toute accumulation.gradle, de sorte que certains projets ont également mis la dépendance de la version ou de divulguer des renseignements en gradle.properties, mais c'est probablement un abus de ce fichier.

    gradle/utils.gradle

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

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

    buildSrc/...

    Ce dossier est spécial, c'est une autre gradle projet en lui-même. Il est construit avant tout autre chose, et peut fournir la fonction à utiliser dans tout autre gradle fichier. Pour des raisons techniques, l'IDE prise en charge des références pour ce dossier de travail beaucoup mieux que tout autre moyen d'extraire le code commun à partir de plusieurs build.gradle fichiers à un autre emplacement.
    Vous pouvez définir des complexes de génération personnalisée, logique en java, groovy ou de kotlin, au lieu de l'écriture et le déploiement d'un plugin. C'est également utile pour les tests unitaires votre version personnalisée de code, que vous pouvez avoir des tests unitaires.

    InformationsquelleAutor tkruse