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

1. Oversigt

I denne artikel vi ser på de forskellige konfigurationsfiler i et Gradle Java-projekt. Vi vil også se detaljerne i en faktisk build.

Du kan tjekke denne artikel for en generel introduktion til Gradle.

2. build.gradle

Lad os antage, at vi bare opretter et nyt Java-projekt ved at køre grad init - Java-applikationstype. Dette giver os et nyt projekt med følgende bibliotek 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 overveje build.gradle fil som projektets hjerte eller hjerne. Den resulterende fil til vores eksempel ser sådan ud:

plugins {id 'java' id 'application'} mainClassName = 'App' afhængigheder {kompilér 'com.google.guava: guava: 23.0' testCompile 'junit: junit: 4.12'} repositories {jcenter ()}

Den består af Groovy-kode eller mere præcist en Groovy-baseret DSL (domænespecifikt sprog) til beskrivelse af builds. Vi kan definere vores afhængigheder her og også tilføje ting som Maven-arkiver, der bruges til afhængighedsopløsning.

De grundlæggende byggesten i Gradle er projekter og opgaver. I dette tilfælde, da java plugin anvendes, alle nødvendige opgaver til opbygning af et Java-projekt defineres implicit. Nogle af disse opgaver er samle, kontrollere, bygge, krukke, javadoc, ren og mange flere.

Disse opgaver er også indstillet på en sådan måde, at de beskriver en nyttig afhængighedsgraf for et Java-projekt, hvilket betyder, at det generelt er nok til at udføre byggeopgaven, og Gradle (og Java-pluginet) vil sikre, at alle nødvendige opgaver udføres .

Hvis vi har brug for yderligere specialiserede opgaver, som f.eks. At opbygge et Docker-billede, ville det også gå ind i build.gradle fil. Den nemmest mulige definition af opgaver ser sådan ud:

opgave hej {doLast {println 'Hej Baeldung!' }}

Vi kan køre en opgave ved at specificere den som et argument til Gradle CLI sådan:

$ gradle -q hej Hej Baeldung!

Det gør intet nyttigt, men udskriver "Hej Baeldung!" selvfølgelig.

I tilfælde af en flerprojektopbygning ville vi sandsynligvis have flere forskellige build.gradle filer, en til hvert projekt.

Det build.gradle filen udføres mod en Projekt forekomst med en projektinstans oprettet pr. underprojekt. Ovenstående opgaver, som kan defineres i build.gradle fil, befinder sig inde i Projekt eksempel som en del af en samling af Opgave genstande. Selve opgaverne består af flere handlinger som en ordnet liste.

I vores tidligere eksempel har vi tilføjet en Groovy-lukning til udskrivning af "Hej Baeldung!" til slutningen af denne liste ved at ringe til doLast (lukning) på vores HejOpgave objekt. Under udførelsen af Opgave, Gradle udfører hver af sine Handlinger i orden ved at ringe til Action. Udfør (T) metode.

3. settings.gradle

Gradle genererer også en settings.gradle fil:

rootProject.name = 'gradle-eksempel'

Det settings.gradle filen er også et Groovy-script.

I modsætning til build.gradle fil, kun en settings.gradle filen udføres pr. Gradle-build. Vi kan bruge det til at definere projekterne i en flerprojektbygning.

Desuden kan vi også registrere kode som en del af forskellige livscykluskroge i en bygning.

Rammen kræver eksistensen af settings.gradle i en flerprojektopbygning, mens den er valgfri til en enkeltprojektopbygning.

Denne fil bruges efter oprettelse af Indstillinger forekomst af buildet ved at udføre filen mod den og derved konfigurere den. Dette betyder, at vi definerer delprojekter i vores settings.gradle fil som denne:

inkluderer 'foo', 'bar'

og Gradle kalder ugyldigt inkluderer (String ... projectPaths) metode til Indstillinger eksempel, når du opretter build.

4. gradle.egenskaber

Gradle opretter ikke en gradle.egenskaber fil som standard. Det kan opholde sig forskellige steder, for eksempel i projektets rodmappe, inde i GRADLE_USER_HOME eller på det sted, der er angivet af -Dgradle.user.home kommandolinjeflag.

Denne fil består af nøgleværdipar. Vi kan bruge det til at konfigurere selve rammens opførsel, og det er et alternativ til at bruge kommandolinjeflag til konfigurationen.

Eksempler på mulige nøgler er:

org.gradle.caching = (sand, falsk)
org.gradle.daemon = (sand, falsk)
org.gradle.parallel = (true, false)
org.gradle.logging.level = (stille, advarsel, livscyklus, info, fejlretning)

Du kan også bruge denne fil til at tilføje egenskaber direkte til Projekt objekt, f.eks. ejendommen med dens navneområde: org.gradle.project.property_to_set

En anden brugssag er at specificere JVM-parametre som denne:

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

Bemærk, at det er nødvendigt at starte en JVM-proces for at analysere gradle.egenskaber fil. Dette betyder, at disse JVM-parametre kun påvirker separat lancerede JVM-processer.

5. Bygningen i en nøddeskal

Vi kan sammenfatte den generelle livscyklus for en Gradle-build som følger, forudsat at vi ikke kører den som en dæmon:

Det lanceres som en ny JVM-proces
Det analyserer gradle.egenskaber fil og konfigurerer Gradle i overensstemmelse hermed
Dernæst skaber det en Indstillinger eksempel på build
Derefter evaluerer den settings.gradle arkiv mod Indstillinger objekt
Det skaber et hierarki af Projekter, baseret på det konfigurerede Indstillinger objekt
Endelig udfører den hver build.gradle fil mod projektet

6. Konklusion

Vi har set, hvordan forskellige Gradle-konfigurationsfiler opfylder forskellige udviklingsformål. Vi kan bruge dem til at konfigurere en Gradle-build såvel som Gradle selv baseret på behovene i vores projekt.

streamalism.org