Quando utilizzare gradle.properties e settings.gradle?

Una build gradle ha tre file

• build.gradle che definisce gli script di configurazione della build
• gradle.properties
• settings.gradle

Domande

• Quali sono le differenze tra settings.gradle& gradle.properties?
• Quando è necessario inserire le impostazioni settings.gradlevs. gradle.properties?

settings.gradle

Il settings.gradlefile è uno script Groovy, proprio come il build.gradlefile. settings.gradleVerrà eseguito un solo script in ogni build (rispetto a più build.gradlescript in build multi-progetto). Lo settings.gradlescript verrà eseguito prima di qualsiasi build.gradlescript e anche prima della Projectcreazione delle istanze. Pertanto, viene valutato rispetto a un Settingsoggetto. Con questo Settingsoggetto è possibile aggiungere sottoprogetti alla build, modificare i parametri dalla riga di comando ( StartParameter) e accedere Gradleall'oggetto per registrare i gestori del ciclo di vita. Di conseguenza, utilizzare settings.gradlese le impostazioni sono correlate alla build e non necessariamente al progetto o richiedono logica prima di includere possibili sottoprogetti.

gradle.properties

Il gradle.propertiesfile è un semplice Propertiesfile Java che acquisisce un ruolo speciale solo essendo automaticamente incluso nell'ambito Projectdell'oggetto (come le cosiddette "proprietà del progetto"). È un semplice archivio di valori-chiave che consente solo valori stringa (quindi è necessario dividere elenchi o array da soli). Puoi mettere i gradle.propertiesfile in queste posizioni:

• direttamente nella directory del progetto (per i valori relativi al progetto)
• nella home .gradledirectory dell'utente (per valori relativi all'utente o all'ambiente)

Un progetto multimodulo ha un modulo principale e molti sottomoduli. Ha questo layout:

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

i sottomoduli possono anche essere posizionati più in profondità nelle sottocartelle, ma senza modificare il codice in settings.gradle, il loro nome includerà il nome di tali cartelle.

settings.gradle

Il ruolo principale di settings.gradle è definire tutti i sottomoduli inclusi e contrassegnare la directory root di un albero di moduli, in modo che tu possa avere un solo settings.gradlefile in un progetto multi-modulo.

rootProject.name = 'project-x'

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

Anche il file delle impostazioni è scritto in groovy e la ricerca del sottomodulo può essere personalizzata.

build.gradle

Esiste uno di questi file per modulo, contiene la logica di compilazione per questo modulo.

Nel build.gradlefile del modulo principale è possibile utilizzare allprojects {}o subprojects {}per definire le impostazioni per tutti gli altri moduli.

Nel build.gradlefile dei sottomoduli, puoi usare compile project(':sub-a')per far dipendere un sottomodulo dall'altro.

gradle.properties

Questo è opzionale, il suo scopo principale è fornire opzioni di avvio da usare per eseguire lo stesso gradle, ad es

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

Questi valori possono essere sovrascritti da un file USER_HOME/.gradle/gradle.propertiese sovrascritti da argomenti della riga di comando gradle. Inoltre è possibile impostare variabili di ambiente per la compilazione in questo file utilizzando systemProp.come prefisso.

Qualsiasi proprietà in questo file può essere utilizzata in qualsiasi build.gradle, quindi alcuni progetti inseriscono anche informazioni sulla versione della dipendenza o sulla versione gradle.properties, ma questo è probabilmente un abuso di questo file.

my-gradle-stuff / utils.gradle

(È possibile qualsiasi nome di cartella o file.) È possibile definire file gradle personalizzati aggiuntivi per riutilizzare le definizioni e includerli in altri file gradle tramite

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

altri posti dove mettere questo potrebbero essere src/gradleosrc/build/gradle

buildSrc / ...

Questa cartella è speciale, è come un progetto gradle separato in sé. È costruito prima di fare qualsiasi altra cosa e può fornire funzioni da utilizzare in qualsiasi altro file gradle. Per motivi tecnici, il supporto IDE per i riferimenti a questa cartella funziona molto meglio di qualsiasi altro modo di estrarre codice comune da più build.gradlefile in una posizione separata.

Puoi definire una complessa logica di compilazione personalizzata in java, groovy o kotlin, invece di scrivere e distribuire un plugin. Ciò è utile anche per testare le unità del codice di build personalizzato, poiché è possibile eseguire test di unità. La struttura della cartella sorgente in buildSrcpuò essere adattata come per qualsiasi progetto java / groovy / kotlin.