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

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

1. Überblick

In diesem Artikel werdenwe’ll look at the different configuration files of a Gradle Java project. Also, we’ll see the details of an actual build.

Sie könnenthis article überprüfen, um eine allgemeine Einführung in Gradle zu erhalten.

2. build.gradle

Nehmen wir an, wir erstellen nur ein neues Java-Projekt, indem wirgradle init –type java-application ausführen. Dadurch erhalten wir ein neues Projekt mit der folgenden Verzeichnis- und Dateistruktur:

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

Wir können diebuild.gradle-Datei als das Herz oder das Gehirn des Projekts betrachten. Die resultierende Datei für unser Beispiel sieht folgendermaßen aus:

plugins {
    id 'java'
    id 'application'
}

mainClassName = 'App'

dependencies {
    compile 'com.google.guava:guava:23.0'

    testCompile 'junit:junit:4.12'
}

repositories {
    jcenter()
}

Es besteht aus Groovy-Code, genauer gesagt einem Groovy-basierten DSL (domänenspezifische Sprache) zur Beschreibung der Builds. Wir können hier unsere Abhängigkeiten definieren und auch Dinge wie Maven-Repositorys hinzufügen, die für die Auflösung von Abhängigkeiten verwendet werden.

Die Grundbausteine ​​von Gradle sind Projekte und Aufgaben. In diesem Fall werden, da das Pluginjavaangewendet wird, alle erforderlichen Aufgaben zum Erstellen eines Java-Projekts implizit definiert. Einige dieser Aufgaben sindassemble,check,build,jar,javadoc,clean und viele mehr.

Diese Aufgaben sind auch so eingerichtet, dass sie ein nützliches Abhängigkeitsdiagramm für ein Java-Projekt beschreiben. Dies bedeutet, dass es im Allgemeinen ausreicht, die Build-Aufgabe auszuführen, und Gradle (und das Java-Plugin) stellen sicher, dass alle erforderlichen Aufgaben ausgeführt werden .

Wenn wir zusätzliche spezielle Aufgaben benötigen, wie z. B. das Erstellen eines Docker-Images, wird es auch in die Dateibuild.gradleaufgenommen. Die einfachste Definition von Aufgaben sieht so aus:

task hello {
    doLast {
        println 'Hello example!'
    }
}

Wir können eine Aufgabe ausführen, indem wir sie wie folgt als Argument für die Gradle-CLI angeben:

$ gradle -q hello
Hello example!

Es wird nichts Nützliches tun, aber "Hallo Beispiel!" natürlich.

Bei einem Build mit mehreren Projekten haben wir wahrscheinlich mehrere verschiedenebuild.gradle-Dateien, eine für jedes Projekt.

Die Dateibuild.gradlewird für eineProject-Instanz ausgeführt, wobei pro Unterprojekt eine Projektinstanz erstellt wird. Die oben genannten Aufgaben, die in der Dateibuild.gradledefiniert werden können, befinden sich in der Instanz vonProjectals Teil einer Sammlung vonTask-Objekten. Die Aufgaben selbst bestehen aus mehreren Aktionen als geordnete Liste.

In unserem vorherigen Beispiel haben wir einen Groovy-Verschluss zum Ausdrucken von "Hallo Beispiel!" Hinzugefügt. bis zum Ende dieser Liste, indem SiedoLast(Closure action) für unserhelloTask-Objekt aufrufen. Während der Ausführung vonTask führt Gradle jedes seinerActions der Reihe nach aus, indem er die MethodeAction.execute(T) aufruft.

3. settings.gradle

Gradle generiert auch einesettings.gradle-Datei:

rootProject.name = 'gradle-example'

Diesettings.gradle-Datei ist ebenfalls ein Groovy-Skript.

Im Gegensatz zurbuild.gradle-Datei wird nur einesettings.gradle-Datei pro Gradle-Build ausgeführt. Wir können es verwenden, um die Projekte eines Builds mit mehreren Projekten zu definieren.

Außerdem können wir auch Code als Teil verschiedener Lifecycle-Hooks eines Builds registrieren.

Das Framework erfordert das Vorhandensein vonsettings.gradle in einem Build mit mehreren Projekten, während es für einen Build mit einem einzelnen Projekt optional ist.

Diese Datei wird nach dem Erstellen derSettings-Instanz des Builds verwendet, indem die Datei dagegen ausgeführt und dadurch konfiguriert wird. Dies bedeutet, dass wir Teilprojekte in unserersettings.gradle-Datei wie folgt definieren:

include 'foo', 'bar'

und Gradle ruft beim Erstellen des Builds die Methodevoid include(String… projectPaths)für die InstanzSettingsauf.

4. gradle.properties

Gradle erstellt standardmäßig keinegradle.properties-Datei. Es kann sich an verschiedenen Speicherorten befinden, z. B. im Projektstammverzeichnis, innerhalb vonGRADLE_USER_HOME oder an dem durch das Befehlszeilenflag-Dgradle.user.home angegebenen Speicherort.

Diese Datei besteht aus Schlüssel-Wert-Paaren. Wir können es verwenden, um das Verhalten des Frameworks selbst zu konfigurieren, und es ist eine Alternative zur Verwendung von Befehlszeilenflags für die Konfiguration.

Beispiele für mögliche Schlüssel sind:

  • org.gradle.caching=(true,false)

  • org.gradle.daemon=(true,false)

  • org.gradle.parallel=(true,false)

  • org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)

Sie können diese Datei auch verwenden, um Eigenschaften direkt zum ObjektProjecthinzuzufügen, z. B. die Eigenschaft mit ihrem Namespace:org.gradle.project.property_to_set

Ein weiterer Anwendungsfall ist die Angabe von JVM-Parametern wie folgt:

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

Bitte beachten Sie, dass ein JVM-Prozess gestartet werden muss, um diegradle.properties-Datei zu analysieren. Dies bedeutet, dass diese JVM-Parameter nur separat gestartete JVM-Prozesse betreffen.

5. Der Build in Kürze

Wir können den allgemeinen Lebenszyklus eines Gradle-Builds wie folgt zusammenfassen, vorausgesetzt, wir führen ihn nicht als Daemon aus:

  • Es wird als neuer JVM-Prozess gestartet

  • Es analysiert diegradle.properties-Datei und konfiguriert Gradle entsprechend

  • Als Nächstes wird eineSettings-Instanz für den Build erstellt

  • Anschließend wertet es die Dateisettings.gradlegegen das ObjektSettingsaus

  • Es wird eine Hierarchie vonProjects basierend auf dem konfiguriertenSettings-Objekt erstellt

  • Schließlich führt es jedebuild.gradle-Datei für sein Projekt aus

6. Fazit

Wir haben gesehen, wie unterschiedliche Gradle-Konfigurationsdateien verschiedene Entwicklungszwecke erfüllen. Wir können sie verwenden, um einen Gradle-Build sowie Gradle selbst basierend auf den Anforderungen unseres Projekts zu konfigurieren.