Hallo Spaß-Coder.
Wir haben uns hier im Blog bereits mit der Frage beschäftigt, wie in einem Softwareprojekt Abhängigkeiten zu Fremdbibliotheken verwaltet werden können und der gesamte Lebenszyklus einer Software unterstützt wird. Hierzu kann das Werkzeug Maven eingesetzt werden. Artikel dazu findet ihr unter diesem Stichwort.
In diesem Artikel werden wir uns anschauen, welche Alternative es zu Maven gibt und wann diese sinnvoll eingesetzt werden kann. Je doch sei in dieser Stelle darauf hinwiesen, dann dieser Artikel nur an der Oberfläche von Gradle kratzt und wenige Einblicke gibt. Weiterführende Infos findet ihr in den Verweisen.
Wer ist dieser Gradle?
Gradle wird von seinen Entwicklern als Build-Werkzeug mit Quantensprung in der Java-Welt bezeichnet. Ähnlich zu Maven arbeitet Gradle mit Konventionen, die – falls genutzt – eine aufwendige Konfiguration überflüssig machen. Nur Abweichungen von den Konventionen müssen explizit gemacht werden (build by convention). Abhängigkeiten werden unter Anbindung von Maven-Repositories verwaltet und auch der Lebenszyklus mehrerer Projekte wird unterstützt.
Gradle kann natürlich, wie andere Tools auch, heruntergeladen und installiert werden oder durch eine Integration der Entwicklungsumgebung genutzt werden. Darüber hinaus bietet Gradle jedoch eine weitere Variante ganz ohne Installation – den Gradle-Wrapper. Hierbei befindet sich Gradle in einem Java-Archiv und kann ganz ohne Installation genutzt werden.
Die Entwicklungsumgebung IntelliJ bietet beispielsweise eine Integration zu Gradle. Wird ein neues Gradle-Projekt erstellt, kann die verwendete Art von Gradle ausgewählt werden, der Gradle-Wrapper ist dabei eine Option. IntelliJ legt automatisch im Projektverzeichnis einen Ordner „gradle“ mit der jar-Datei sowie einer Properties-Datei an. Nun kann Gradle genutzt werden.
Wie sieht Gradle denn nun aus?
Schauen wir uns eine einfache Gradle-Konfiguration an, welche üblicherweise (nach Konvention) aus zwei Bestandteilen besteht:
- eine Datei mit Einstellungen (settings.gradle) und
- die Build-Beschreibung (build.gradle).
Hier nun ein Beispiel aus einem kleinen Projekt.
settings.gradle
1 |
rootProject.name = 'AbstractFactory' |
build.gradle
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
group 'de.invidit' apply plugin: 'java' sourceCompatibility = 1.8 repositories { mavenCentral() } dependencies { testCompile group: 'junit', name: 'junit', version: '4.11' testCompile 'org.assertj:assertj-core:3.3.0' } |
Gehen wir die beiden Dateien einmal durch. In den Einstellungen legen wir nur den Projektnamen fest, der z.B. in der IDE angezeigt wird oder auf den wir an anderer Stelle verweisen können. Die Beschreibung des Builds beginnt mit der Group-Id. Wie auch bei Maven wird unserem Projekt eine eindeutige Id zugewiesen. Darüber, gemeinsam mit dem Projektnamen, können wir das Projekt z.B. aus einem Repository abrufen.
Dann legen wir fest, dass wir das Java-Plugin für Gradle nutzen wollen. Dieses bietet für Java-Projekte einige hilfreiche Schritte im Lebenszyklus unseres Projekts, die wir uns später noch anschauen. Unsere Programmquellen sollen gegen Java 8 geprüft werden, was wir mit „sourceCompatibility“ festlegen. Dann geben wir das zentrale Maven-Repository an, in dem die im nächsten Schritt angegebenen Abhängigkeiten zu finden sind. In diesem Projekt benötigen wir zum Ausführen von Tests zwei externe Bibliotheken, nämlich JUnit und AssertJ. Da wir uns diese nicht selbst herunterladen und in unser Projekt einbinden wollen, definieren wir in unserer Build-Datei diese beiden Abhängigkeiten. Das verwendete Java-Plugin bietet uns verschiedene Konfiguration um festzulegen, zu welchem Zeitpunkt unsere Abhängigkeiten benötigt werden. Für JUnit und AssertJ geben wir „testCompile“ an. Dies bedeutet, dass zum Kompilieren unserer Testklassen diese beiden Abhängigkeiten benötigt werden. Unser Produktionscode wird hierbei automatisch ebenfalls in den Klassenpfad aufgenommen – sonst würden die Test auch kaum funktionieren.
Wie euch sicherlich aufgefallen ist, lassen sich die Abhängigkeiten in verschiedenen Schreibweisen angeben. Sucht ihr im Maven-Repository nach einer Bibliothek und lasst euch den Gradle-Snippet dazu geben, sieht er so aus wie bei AssertJ in unserem Beispiel. Das ist die Kurzschreibweise zur der längeren Variante bei JUnit (dieser Eintrag wird von IntelliJ automatisch beim Erstellen eines Gradle-Projekts hinzugefügt – ist wohl ein Wink mit dem Scheunentor ;-).
Und jetzt?
Jetzt können wir unser Projekt bauen lassen, testen lassen und andere Sachen machen lassen. Aber wie? Hier gibt es zwei Möglichkeiten. Im Projektverzeichnis rufen wir auf der Befehlszeile „gradlew build“ auf, um unser Projekt zu bauen. „gradlew“ ist der Einstiegspunkt für unseren Gradle-Wrapper und wird per IntelliJ automatisch generiert, als Batch-Datei und als Shell-Script. Anschließend geben wir die auszuführende Aufgabe an, in diesem Fall „build“.
Die zweite Möglichkeit ist die Ausführung von Gradle-Aufgaben per IDE, was in IntelliJ zum Beispiel so aussieht. Hier sind alle durch unsere verwendeten Plugins bereitgestellten Aufgaben sowie die Abhängigkeiten zu sehen. Per Doppelklick kann nun z.B. der build oder unsere Tests gestartet werden. In dieser Darstellung seht ihr auch, wie die Gradle-Projektstruktur abgebildet ist. Im gezeigten Beispiel gibt es ein Projekt „CodeQuality“ und darunter mehrere Teilprojekte. Zu jedem Teilprojekt können Aufgaben einzeln ausgeführt werden, oder sie werden auf Hauptprojekte-Ebene für alle Teilprojekte aufgerufen.
Wann nehme ich denn welches Werkzeug?
An dieser Stelle möchten wir auf den Artikel[1] verweisen. Hier werden anhand verschiedener Kriterien und Einsatzszenarios unter anderem Maven und Gradle miteinander verglichen. Als Fazit wird genannt, dass Gradle schneller und leichtgewichtiger ist als Maven und mehr und einfachere Möglichkeiten abseits der Konventionen zulässt. Maven ist hingegen (zum Zeitpunkt des Vergleichs) deutlich besser in gängige Entwicklungsumgebungen integriert.
Zusammenfassung?
In diesem Artikel haben wir einen kurzen Blick auf das Build-Werkzeug Gradle als Alternative zu Maven geworfen. Dabei haben wir ein einfaches Projekt konfiguriert und Aufgaben aus dem Java-Plugin zu Gradle genutzt, um unseren Java-Quellecode zu kompilieren.
In welchen Situationen habt ihr bisher Vor- und Nachteile von Gradle zu Maven erfahren? Oder nutzt ihr sogar noch andere Build-Werkzeuge? Welche?
Eure Spaß-Coder
Dieser Artikel basiert neben unseren Erfahrungen auf den Ausführungen aus:
- https://docs.gradle.org/current/userguide/introduction.html
- [1] http://zeroturnaround.com/rebellabs/java-build-tools-part-2-a-decision-makers-comparison-of-maven-gradle-and-ant-ivy/