Gradle: build.gradle vs. settings.gradle vs. gradle.properties

1. Oversikt

I denne artikkelen, vi ser på de forskjellige konfigurasjonsfilene til et Gradle Java-prosjekt. Vi vil også se detaljene i en faktisk bygging.

Du kan sjekke denne artikkelen for en generell introduksjon til Gradle.

2. build.gradle

La oss anta at vi bare lager et nytt Java-prosjekt ved å kjøre gradering init –type java-applikasjon. Dette gir oss et nytt prosjekt med følgende katalog og filstruktur:

build.gradle gradle wrapper gradle-wrapper.jar gradle-wrapper.properties gradlew gradlew.bat settings.gradle src main java App.java test java AppTest.java

Vi kan vurdere build.gradle filen som hjertet eller hjernen til prosjektet. Den resulterende filen for vårt eksempel ser slik ut:

plugins {id 'java' id 'application'} mainClassName = 'App' avhengigheter {compile 'com.google.guava: guava: 23.0' testCompile 'junit: junit: 4.12'} repositories {jcenter ()}

Den består av Groovy-kode, eller mer presist, et Groovy-basert DSL (domenespesifikt språk) for å beskrive byggene. Vi kan definere våre avhengigheter her og også legge til ting som Maven-arkiver som brukes til avhengighetsoppløsning.

De grunnleggende byggesteinene til Gradle er prosjekter og oppgaver. I dette tilfellet, siden java plugin brukes, blir alle nødvendige oppgaver for å bygge et Java-prosjekt definert implisitt. Noen av disse oppgavene er montere, Sjekk, bygge, krukke, javadoc, ren og mange flere.

Disse oppgavene er også satt opp på en slik måte at de beskriver en nyttig avhengighetsgraf for et Java-prosjekt, noe som betyr at det generelt er nok å utføre byggeoppgaven og Gradle (og Java-plugin) vil sørge for at alle nødvendige oppgaver blir utført .

Hvis vi trenger flere spesialiserte oppgaver, for eksempel å bygge et Docker-bilde, vil det også gå inn i build.gradle fil. Den enkleste mulige definisjonen av oppgaver ser slik ut:

oppgave hei {doLast {println 'Hallo Baeldung!' }}

Vi kan kjøre en oppgave ved å spesifisere den som et argument til Gradle CLI slik:

$ gradle -q hallo hei Baeldung!

Det vil ikke gjøre noe nyttig, men skrive ut "Hei Baeldung!" selvfølgelig.

I tilfelle en flerprosjektbygging, ville vi sannsynligvis ha flere forskjellige build.gradle filer, en for hvert prosjekt.

De build.gradle filen kjøres mot en Prosjekt forekomst, med en prosjektforekomst opprettet per delprosjekt. Oppgavene ovenfor, som kan defineres i build.gradle filen, bor inne i Prosjekt forekomst som en del av en samling av Oppgave gjenstander. Oppgavene i seg selv består av flere handlinger som en ordnet liste.

I vårt forrige eksempel har vi lagt til en Groovy-lukking for utskrift av "Hello Baeldung!" til slutten av denne listen, ved å ringe doLast (lukkingshandling) på vår HalloOppgave gjenstand. Under utførelsen av Oppgave, Gradle utfører hvert sitt Handlinger i orden, ved å ringe Action. Utfør (T) metode.

3. settings.gradle

Gradle genererer også en settings.gradle fil:

rootProject.name = 'gradle-eksempel'

De settings.gradle filen er også et Groovy-skript.

I motsetning til build.gradle fil, bare en settings.gradle filen utføres per Gradle-build. Vi kan bruke den til å definere prosjektene til en flerprosjektbygging.

Dessuten kan vi også registrere kode som en del av forskjellige livssykluskroker i en bygning.

Rammeverket krever eksistensen av settings.gradle i en flerprosjektbygging, mens det er valgfritt for et enkeltprosjektbygging.

Denne filen brukes etter at du har opprettet Innstillinger forekomsten av bygningen, ved å kjøre filen mot den og derved konfigurere den. Dette betyr at vi definerer delprosjekter i vårt settings.gradle fil slik:

inkluderer 'foo', 'bar'

og Gradle kaller void include (String ... projectPaths) metoden på Innstillinger eksempel når du oppretter build.

4. gradle.egenskaper

Gradle lager ikke en gradle.egenskaper fil som standard. Den kan ligge på forskjellige steder, for eksempel i prosjektets rotkatalog, inne i GRADLE_USER_HOME eller på stedet spesifisert av -Dgradle.user.home kommandolinjeflagg.

Denne filen består av nøkkelverdipar. Vi kan bruke den til å konfigurere oppførselen til selve rammeverket, og det er et alternativ til å bruke kommandolinjeflagg for konfigurasjonen.

Eksempler på mulige nøkler er:

  • org.gradle.caching = (true, false)
  • org.gradle.daemon = (true, false)
  • org.gradle.parallel = (true, false)
  • org.gradle.logging.level = (stille, advare, livssyklus, info, feilsøking)

Du kan også bruke denne filen til å legge til egenskaper direkte til Prosjekt objektet, for eksempel eiendommen med navnområdet: org.gradle.project.property_to_set

En annen brukssak er å spesifisere JVM-parametere som dette:

org.gradle.jvmargs = -Xmx2g -XX: MaxPermSize = 256m -XX: + HeapDumpOnOutOfMemoryError -Dfile.encoding = UTF-8

Vær oppmerksom på at den må starte en JVM-prosess for å analysere gradle.egenskaper fil. Dette betyr at disse JVM-parametrene bare påvirker separat lanserte JVM-prosesser.

5. Bygg i et nøtteskall

Vi kan oppsummere den generelle livssyklusen til en Gradle-bygning på følgende måte, forutsatt at vi ikke kjører den som en demon:

  • Den lanseres som en ny JVM-prosess
  • Det analyserer gradle.egenskaper fil og konfigurerer Gradle deretter
  • Deretter skaper det en Innstillinger eksempel for bygg
  • Deretter evaluerer den settings.gradle arkiv mot Innstillinger gjenstand
  • Det skaper et hierarki av Prosjekter, basert på den konfigurerte Innstillinger gjenstand
  • Til slutt utfører den hver build.gradle filen mot prosjektet

6. Konklusjon

Vi har sett hvordan forskjellige Gradle-konfigurasjonsfiler oppfyller ulike utviklingsformål. Vi kan bruke dem til å konfigurere en Gradle-bygning så vel som Gradle selv, basert på behovene til prosjektet vårt.


$config[zx-auto] not found$config[zx-overlay] not found