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

1. Overzicht

In dit artikel, we zullen de verschillende configuratiebestanden van een Gradle Java-project bekijken. We zullen ook de details van een daadwerkelijke build zien.

U kunt dit artikel raadplegen voor een algemene inleiding tot Gradle.

2. build.gradle

Laten we aannemen dat we gewoon een nieuw Java-project maken door uit te voeren gradle init –type java-applicatie. Dit geeft ons een nieuw project met de volgende map- en bestandsstructuur:

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

We kunnen de build.gradle bestand als het hart of het brein van het project. Het resulterende bestand voor ons voorbeeld ziet er als volgt uit:

plug-ins {id 'java' id 'application'} mainClassName = 'App'-afhankelijkheden {compileren' com.google.guava: guava: 23.0 'testCompile' junit: junit: 4.12 '} repositories {jcenter ()}

Het bestaat uit Groovy-code, of beter gezegd, een op Groovy gebaseerde DSL (domeinspecifieke taal) voor het beschrijven van de builds. We kunnen hier onze afhankelijkheden definiëren en ook dingen toevoegen zoals Maven-repositories die worden gebruikt voor het oplossen van afhankelijkheden.

De fundamentele bouwstenen van Gradle zijn projecten en taken. In dit geval, aangezien de Java plug-in wordt toegepast, worden alle noodzakelijke taken voor het bouwen van een Java-project impliciet gedefinieerd. Sommige van die taken zijn monteren, controleren, bouwen, pot, javadoc, schoon en nog veel meer.

Deze taken zijn ook zo opgezet dat ze een bruikbare afhankelijkheidsgrafiek voor een Java-project beschrijven, wat betekent dat het over het algemeen voldoende is om de build-taak uit te voeren en Gradle (en de Java-plug-in) ervoor zal zorgen dat alle noodzakelijke taken worden uitgevoerd .

Als we aanvullende gespecialiseerde taken nodig hebben, zoals bijvoorbeeld het bouwen van een Docker-image, gaat deze ook naar het build.gradle het dossier. De eenvoudigst mogelijke definitie van taken ziet er als volgt uit:

taak hallo {doLast {println 'Hallo Baeldung!' }}

We kunnen een taak uitvoeren door deze als een argument voor de Gradle CLI als volgt op te geven:

$ gradle -q hallo Hallo Baeldung!

Het zal niets nuttigs doen, maar print "Hallo Baeldung!" natuurlijk.

In het geval van een build met meerdere projecten, hebben we waarschijnlijk meerdere verschillende build.gradle bestanden, één voor elk project.

De build.gradle bestand wordt uitgevoerd tegen een Project instantie, met één projectinstantie gemaakt per subproject. De bovenstaande taken, die kunnen worden gedefinieerd in het build.gradle bestand, bevinden zich in het Project exemplaar als onderdeel van een verzameling van Taak voorwerpen. De taken zelf bestaan ​​uit meerdere acties als een geordende lijst.

In ons vorige voorbeeld hebben we een Groovy-sluiting toegevoegd voor het afdrukken van "Hallo Baeldung!" aan het einde van deze lijst door de doLast (sluitingsactie) op onze HalloTaak voorwerp. Tijdens de uitvoering van Taak, Gradle voert elk van zijn Acties in volgorde door de Action.execute (T) methode.

3. settings.gradle

Gradle genereert ook een settings.gradle het dossier:

rootProject.name = 'gradle-voorbeeld'

De settings.gradle bestand is ook een Groovy-script.

In tegenstelling tot build.gradle bestand, slechts één settings.gradle bestand wordt uitgevoerd per Gradle-build. We kunnen het gebruiken om de projecten van een build met meerdere projecten te definiëren.

Daarnaast is het ook mogelijk om code te registreren als onderdeel van verschillende life cycle hooks van een build.

Het framework vereist het bestaan ​​van de settings.gradle in een build met meerdere projecten, terwijl het optioneel is voor een build met één project.

Dit bestand wordt gebruikt nadat het Instellingen instantie van de build, door het bestand ertegen uit te voeren en het daardoor te configureren. Dit betekent dat we deelprojecten definiëren in ons settings.gradle bestand als dit:

omvatten 'foo', 'bar'

en Gradle roept de void include (String… projectPaths) methode op de Instellingen bijvoorbeeld bij het maken van de build.

4. gradle.properties

Gradle maakt geen gradle.properties bestand standaard. Het kan zich op verschillende locaties bevinden, bijvoorbeeld in de hoofdmap van het project, in GRADLE_USER_HOME of op de locatie die is opgegeven door de -Dgradle.user.home opdrachtregel vlag.

Dit bestand bestaat uit sleutel / waarde-paren. We kunnen het gebruiken om het gedrag van het framework zelf te configureren en het is een alternatief voor het gebruik van opdrachtregelvlaggen voor de configuratie.

Voorbeelden van mogelijke sleutels zijn:

  • org.gradle.caching = (waar, onwaar)
  • org.gradle.daemon = (waar, onwaar)
  • org.gradle.parallel = (waar, onwaar)
  • org.gradle.logging.level = (stil, waarschuwen, levenscyclus, info, debuggen)

U kunt dit bestand ook gebruiken om eigenschappen rechtstreeks toe te voegen aan het Project object, bijv. de eigenschap met zijn naamruimte: org.gradle.project.property_to_set

Een ander gebruiksscenario is het specificeren van JVM-parameters als volgt:

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

Houd er rekening mee dat het een JVM-proces moet starten om het gradle.properties het dossier. Dit betekent dat deze JVM-parameters alleen effect hebben op afzonderlijk gestarte JVM-processen.

5. De build in een notendop

We kunnen de algemene levenscyclus van een Gradle-build als volgt samenvatten, ervan uitgaande dat we deze niet als een daemon uitvoeren:

  • Het wordt gestart als een nieuw JVM-proces
  • Het parseert het gradle.properties bestand en configureert Gradle dienovereenkomstig
  • Vervolgens maakt het een Instellingen bijvoorbeeld voor de build
  • Vervolgens evalueert het de settings.gradle bestand tegen het Instellingen voorwerp
  • Het creëert een hiërarchie van Projecten, gebaseerd op de geconfigureerde Instellingen voorwerp
  • Ten slotte voert het elk uit build.gradle bestand tegen zijn project

6. Conclusie

We hebben gezien hoe verschillende Gradle-configuratiebestanden verschillende ontwikkelingsdoeleinden vervullen. We kunnen ze gebruiken om zowel een Gradle-build als Gradle zelf te configureren, op basis van de behoeften van ons project.