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\u00e4che von Gradle kratzt und wenige Einblicke gibt. Weiterf\u00fchrende Infos findet ihr in den Verweisen.<\/p>\n
<\/p>\n
Wer ist dieser Gradle?<\/h1>\n
Gradle wird von seinen Entwicklern als Build-Werkzeug mit Quantensprung in der Java-Welt bezeichnet. \u00c4hnlich zu Maven arbeitet Gradle mit Konventionen, die – falls genutzt – eine aufwendige Konfiguration \u00fcberfl\u00fcssig machen. Nur Abweichungen von den Konventionen m\u00fcssen explizit gemacht werden (build by convention). Abh\u00e4ngigkeiten werden unter Anbindung von Maven-Repositories verwaltet und auch der Lebenszyklus mehrerer Projekte wird unterst\u00fctzt.<\/p>\n
Gradle kann nat\u00fcrlich, wie andere Tools auch, heruntergeladen und installiert werden oder durch eine Integration der Entwicklungsumgebung genutzt werden. Dar\u00fcber 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.<\/p>\n
Die Entwicklungsumgebung IntelliJ bietet beispielsweise eine Integration zu Gradle. Wird ein neues Gradle-Projekt erstellt, kann die verwendete Art von Gradle ausgew\u00e4hlt 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.<\/p>\n
<\/p>\n
Wie sieht Gradle denn nun aus?<\/h1>\n
Schauen wir uns eine einfache Gradle-Konfiguration an, welche \u00fcblicherweise (nach Konvention) aus zwei Bestandteilen besteht:<\/p>\n
- \n
- eine Datei mit Einstellungen (settings.gradle<\/em>) und<\/li>\n
- die Build-Beschreibung (build.gradle<\/em>).<\/li>\n<\/ul>\n
Hier nun ein Beispiel aus einem kleinen Projekt.<\/p>\n
settings.gradle<\/strong><\/p>\n
rootProject.name = 'AbstractFactory'<\/pre>\n
build.gradle<\/strong><\/p>\n
group 'de.invidit'\r\n\r\napply plugin: 'java'\r\n\r\nsourceCompatibility = 1.8\r\n\r\nrepositories {\r\n mavenCentral()\r\n}\r\n\r\ndependencies {\r\n testCompile group: 'junit', name: 'junit', version: '4.11'\r\n testCompile 'org.assertj:assertj-core:3.3.0'\r\n}<\/pre>\nGehen 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\u00f6nnen. Die Beschreibung des Builds beginnt mit der Group-Id. Wie auch bei Maven wird unserem Projekt eine eindeutige Id zugewiesen. Dar\u00fcber, gemeinsam mit dem Projektnamen, k\u00f6nnen wir das Projekt z.B. aus einem Repository abrufen.<\/p>\n
Dann legen wir fest, dass wir das Java-Plugin f\u00fcr Gradle nutzen wollen. Dieses bietet f\u00fcr Java-Projekte einige hilfreiche Schritte im Lebenszyklus unseres Projekts, die wir uns sp\u00e4ter noch anschauen. Unsere Programmquellen sollen gegen Java 8 gepr\u00fcft werden, was wir mit „sourceCompatibility“ festlegen. Dann geben wir das zentrale Maven-Repository an, in dem die im n\u00e4chsten Schritt angegebenen Abh\u00e4ngigkeiten zu finden sind. In diesem Projekt ben\u00f6tigen wir zum Ausf\u00fchren von Tests zwei externe Bibliotheken, n\u00e4mlich JUnit<\/em> und AssertJ<\/em>. Da wir uns diese nicht selbst herunterladen und in unser Projekt einbinden wollen, definieren wir in unserer Build-Datei diese beiden Abh\u00e4ngigkeiten. Das verwendete Java-Plugin bietet uns verschiedene Konfiguration um festzulegen, zu welchem Zeitpunkt unsere Abh\u00e4ngigkeiten ben\u00f6tigt werden. F\u00fcr JUnit<\/em> und AssertJ<\/em> geben wir „testCompile“ an. Dies bedeutet, dass zum Kompilieren unserer Testklassen diese beiden Abh\u00e4ngigkeiten ben\u00f6tigt werden. Unser Produktionscode wird hierbei automatisch ebenfalls in den Klassenpfad aufgenommen – sonst w\u00fcrden die Test auch kaum funktionieren.<\/p>\n
Wie euch sicherlich aufgefallen ist, lassen sich die Abh\u00e4ngigkeiten 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<\/em> in unserem Beispiel. Das ist die Kurzschreibweise zur der l\u00e4ngeren Variante bei JUnit<\/em> (dieser Eintrag wird von IntelliJ automatisch beim Erstellen eines Gradle-Projekts hinzugef\u00fcgt – ist wohl ein Wink mit dem Scheunentor ;-).<\/p>\n
- die Build-Beschreibung (build.gradle<\/em>).<\/li>\n<\/ul>\n
![\"Gradle_IntelliJ\"](\"http:\/\/invidit.de\/blog\/wp-content\/uploads\/2016\/03\/Gradle_IntelliJ.png\")
<\/a><\/p>\n