Gradle 1.8 will dem Entwickler Zeit sparen

Claudia Fröhling

Das Build-System Gradle hat Version 1.8 erreicht und steht damit kurz vor dem zweiten Major Release. Gradle versteht sich als Toolkit zum Bauen von Softwareprojekten und ist eine mögliche Alternative zu Tools wie Ant und Maven. In Gradle steht eine ausdrucksstarke Build-Sprache zur Verfügung, eine auf Groovy basierende erweiterbare DSL, mit der sich Build-Skripts schreiben lassen. Im Mittelpunkt von Gradle stehen dabei die Tasks, sie führen die eigentlichen Build-Aktionen aus.

Version 1.8 hat einige neue Features spendiert bekommen, die Hans Dockter in seinem Blog hervorhebt. Wie angekündigt unterstützt Gradle jetzt auch Build für C/C++ und Assembler. Damit erweitert das Build-Tool sein Angebot an unterstützten Plattformen, und es sind noch weitere in Planung, wie uns Hans Dockter vor kurzem in einem Interview erzählte. Der C/C++-Support ist noch ausbaufähig, heißt es im Blog. So sollen in den nächsten Wochen noch Incremental Builds und parallele Compilation als Features folgen.

Auch in Sachen Memory Management hat sich bei Gradle 1.8 etwas getan. Bisher hatte Gradle alle Dependency-Informationen im Heap gehalten, was besonders bei großen Builds mit einer Vielzahl von Komponenten zu Problemen führte. Es wurde mehr Memory verbraucht als eigentlich notwendig und die Build-Geschwindigkeit wurde von der Garbage-Collection-Zeit beeinflusst. Ab sofort werden Dependency-Informationen nur noch gespeichert, wenn sie im Heap benötigt werden.

Weitere Zeit wurde in Sachen Import-Geschwindigkeit eingespart. Durch die Überarbeitung des Gradle Tooling API soll das Importieren eines Projekts jetzt nur noch sieben Sekunden dauern. Hans Dockter unterstreicht im Blog noch einmal, wie wichtig die Zusammenarbeit mit JetBrains und Google für die Zukunft des Integration-API ist. Die Rede ist natürlich von Android Studio.

In Gradle 1.8 lassen sich ab sofort auch Status Schemes individuell anpassen. Status Schemes für Komponenten kennt man vor allem aus dem Ivy-Umfeld.

Ab sofort konzentrieren sich die Arbeiten des Gradle-Teams auf das zweite Major Release. Hier geht es laut Hans Dockter vor allem um eine Verschlankung des gesamten Tools. Das heißt, Features, die nicht genutzt werden, sollen deprecated werden. „Getting rid of the “cruft” during a major version upgrade is a healthy part of keeping Gradle lean.”, erklärt er im Blog.

Geschrieben von
Claudia Fröhling
Claudia Fröhling
Claudia Fröhling hat in verschiedenen Redaktionen als TV- und Onlineredakteurin gearbeitet, bevor sie 2008 zur Software & Support Media GmbH kam und sich bis 2014 um alle Projekte des Verlages im Ressort Java kümmerte. Claudia hat einen Abschluss in Politikwissenschaften und Multimedia Producing. Ihr Google+ Profil findest du hier.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.