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

1. Übersicht

In diesem Artikel werden die verschiedenen Konfigurationsdateien eines Gradle Java-Projekts beschrieben . Außerdem sehen wir die Details eines tatsächlichen Builds.

In diesem Artikel finden Sie eine allgemeine Einführung in Gradle.

2. build.gradle

Nehmen wir an, wir erstellen nur ein neues Java-Projekt, indem wir die Java-Anwendung vom Typ gradle init 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 die Datei build.gradle 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 Java- Plugin angewendet wird, alle erforderlichen Aufgaben zum Erstellen eines Java-Projekts implizit definiert. Einige dieser Aufgaben sind Zusammenbauen , Prüfen , Bauen , Glasieren , Javadoc , Reinigen und vieles 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, z. B. das Erstellen eines Docker-Images, wird es auch in die Datei build.gradle aufgenommen . Die einfachste Definition von Aufgaben sieht folgendermaßen aus:

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

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

$ gradle -q hello Hello Baeldung!

Es wird nichts Nützliches tun, aber "Hallo Baeldung!" Na sicher.

Bei einem Build mit mehreren Projekten hätten wir wahrscheinlich mehrere verschiedene build.gradle- Dateien, eine für jedes Projekt.

Die Datei build.gradle wird für eine Projektinstanz ausgeführt , wobei eine Projektinstanz pro Teilprojekt erstellt wird. Die oben genannten Aufgaben, die in der Datei build.gradle definiert werden können, befinden sich in der Projektinstanz als Teil einer Sammlung von Aufgabenobjekten . Die Aufgaben selbst bestehen aus mehreren Aktionen als geordnete Liste.

In unserem vorherigen Beispiel haben wir einen Groovy-Verschluss zum Ausdrucken von „Hallo Baeldung!“ Hinzugefügt. bis zum Ende dieser Liste, indem Sie die doLast (Closure-Aktion) für unser Hallo- Task- Objekt aufrufen . Während der Ausführung von Task führt Gradle jede seiner Aktionen der Reihe nach aus, indem er die Action.execute (T) -Methode aufruft .

3. settings.gradle

Gradle generiert auch eine settings.gradle- Datei:

rootProject.name = 'gradle-example'

Die Datei settings.gradle ist ebenfalls ein Groovy-Skript.

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

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

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

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

include 'foo', 'bar'

und Gradle ruft beim Erstellen des Builds die Methode void include (String… projectPaths) für die Instanz Settings auf .

4. gradle.properties

Gradle erstellt standardmäßig keine gradle.properties- Datei. Es kann sich an verschiedenen Speicherorten befinden, z. B. im Projektstammverzeichnis, innerhalb von GRADLE_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 = (wahr, falsch)
  • org.gradle.daemon = (wahr, falsch)
  • org.gradle.parallel = (wahr, falsch)
  • org.gradle.logging.level = (leise, warnen, Lebenszyklus, Info, Debuggen)

Sie können diese Datei auch verwenden, um Eigenschaften direkt zum Projektobjekt hinzuzufü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 die Datei gradle.properties zu analysieren . Dies bedeutet, dass diese JVM-Parameter nur separat gestartete JVM-Prozesse beeinflussen.

5. Der Build auf den Punkt gebracht

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 die Datei gradle.properties und konfiguriert Gradle entsprechend
  • Als Nächstes wird eine Einstellungsinstanz für den Build erstellt
  • Anschließend wird die Datei settings.gradle anhand des Objekts Settings ausgewertet
  • Es schafft eine Hierarchie der Projekte , basierend auf dem konfigurierten Einstellungen Objekt
  • Schließlich führt es jede build.gradle- Datei für sein Projekt aus

6. Fazit

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