Die neuen Features im Überblick

Gradle 2.0: Ein Meilenstein

Moritz Zimmer, Marek Iwaszkiewicz
©Shutterstock.com/d13

Nach rund zwei Jahren und zwölf Minor-Releases steht mit Version 2.0 das nächste Major-Release des Gradle-Buildsystems zur Verfügung. Was hat sich seit Version 1.0 getan? Welche Änderungen umfasst das aktuelle Major-Release? Was erwartet uns in der Zukunft? Fragen, auf die wir im Folgenden eingehen werden.

Gradle hat bereits in der Version 1.0 viel Aufmerksamkeit erlangt und konnte aufgrund eines frühzeitig stabilen und ausgereiften Standes von Software-Entwicklern und Architekten als Build-System verwendet werden. Die Fragestellung, ob Gradle den Ansprüchen professioneller Software-Projekte genügt und in komplexen Projekten eingesetzt werden kann, konnte früh bejaht werden. Es war dann kaum verwunderlich, dass bei der Wahl des Build-Systems die Entscheidung zunehmend auf Gradle fiel und sich eine große und vor allem aktive Community gebildet hat. So geht zum Beispiel aus dem Jahresbericht der Eclipse Foundation hervor, dass Gradle seinen Marktanteil von 4,5% im Jahr 2013 auf 11,0% im Jahr 2014 mehr als verdoppelt hat.

Da sich auf dem Weg von Version 1.0 zum aktuellen Major-Release viel getan hat, möchten wir im Folgenden zuerst einen Rückblick geben. Anschließend gehen wir auf den aktuellen, mit Version 2.0 erreichten Stand und die wesentlichen darin enthaltenen Features und Änderungen ein. Abschließend geben wir einen Ausblick auf die bereits angekündigten Neuerungen der Roadmap zu Gradle 3.0.

Auf dem Weg zu Gradle 2.0 – ein Rückblick

Aufgrund der hohen Entwicklungsaktivität und der aktiven, stets wachsenden Community sowie des Einsatzes von Continuous Delivery wurden in der Vergangenheit alle sechs bis acht Wochen neue Minor-Releases zur Verfügung gestellt. Die seit Version 1.0 bis zum aktuellen Major-Release umgesetzten Änderungen umfassen sowohl Erweiterungen, Fehlerbehebungen als auch viele Verbesserungen.

In erster Linie lassen sich hier Optimierungen im Bereich der Performance sowie in der effizienteren Speicherauslastung aufführen. Builds einzelner, voneinander unabhängiger Subprojekte im Rahmen komplexer Multi-Projekt-Strukturen können beispielsweise parallel ausgeführt werden, wodurch aktuelle Multi-Core Hardware effizienter genutzt werden kann. Multi-Projekt-Builds profitieren seit Version 1.4 zudem von „Configuration on demand“. Dabei werden in der Konfigurierungsphase nur die Subprojekte einbezogen, die für die tatsächliche Ausführung benötigt werden. Die Möglichkeit zum inkrementellen Bauen von Projekten, also das Überspringen von Tasks, deren Ein- und Ausgabewerte unverändert sind, wurde um sogenannte inkrementelle Tasks erweitert. Diese verarbeiten nur die geänderten Teile der Eingabewerte und ermöglichen somit ein weiteres Plus an Geschwindigkeit. Weitere Optimierungen im Bereich derBuild-Skript-Kompilierung sowie der Speicherauslastung führten zu spürbaren Performanceverbesserungen, von denen insbesondere große Enterprise-Builds profitieren.

Seit Version 1.0 verwendet Gradle ein eigenständiges, zu Maven und Ivy kompatibles Dependency Management. Diese Schlüsselfunktion eines Build-Systems wurde im Rahmen der Minor-Releases stetig im Hinblick auf Performance, Kompatibilität, Konfigurierbarkeit und Reporting verbessert. Die Migration von Maven zu Gradle sowie der initiale Aufwand zum Erstellen neuer Gradle-Projekte wurden zudem durch das Build Init Plugin vereinfacht.

IDE-Integration und Android Studio

Auch auf dem Gebiet der IDE Integration wurden Verbesserungen umgesetzt. Die Integration erfolgt deutlich performanter, wobei alle gängigen Entwicklungsumgebungen mittlerweile über die notwendigen Features verfügen. Mit dem Android Studio existiert zudem die erste vollintegrierte IDE Lösung auf dem Markt. Vollintegriert bedeutet hier, dass Gradle neben der Kommandozeile auch erstmals in der IDE vollständig für den Build zuständig ist. Die Entwicklung des Android Plugins erfolgt dabei von Google in enger Zusammenarbeit mit Gradleware.

Stand Gradle ursprünglich in erster Linie für den Build JVM-basierter Projekte (Java, Groovy, Scala), wurde die Unterstützung nativer Builds sukzessive erweitert. Mittlerweile stellt Gradle Plug-ins zum Erzeugen nativer Software-Komponenten zur Verfügung, die in C/C++, Objective C/C++ oder Assembler Code geschrieben sind. Auch wenn diese Plug-ins derzeit noch als incubating gekennzeichnet sind – sich also in kommenden Releases noch ändern können – bietet Gradle hier Entwicklern und Architekten die Möglichkeit, auf ein einheitliches Build-System zum Erzeugen heterogener Softwareartfakte zurückgreifen.

Eine weitere wichtige neue Komponente stellt das Gradle Plugin Portal dar. Es ersetzt als Web-Portal die bisherige Wiki Lösung und dient als zentrale Anlaufstelle für die Verwaltung und das Auffinden von Plugins.

Version 2.0 – die neue Baseline

Im Rückblick ist erkennbar, dass man sich auf dem schnellen Erfolg und der früh stabilen Gradle-Version nicht ausgeruht hat – ganz im Gegenteil, das Tempo wurde mindestens gehalten und Gradle wurde kontinuierlich verbessert und weiterentwickelt. Was aber bedeutet nun die neue Version 2.0? Immerhin handelt es sich um ein Major Release, bei welchen man in der Regel größere (auch konzeptionelle) Änderungen bis hin zur Re-Implementierung erwarten kann. Genau dies ist aber bei der Version 2.0 von Gradle nicht der Fall. Das aktuelle Release entspricht nicht dem großen strukturelle Änderungen umfassenden Wurf. Und dennoch ist es ein berechtigtes Major Release, das einen wichtigen Meilenstein darstellt.

Deprecated Features und APIs

Wie im Rückblick beschrieben, hat eine kontinuierliche Verbesserung und Weiterentwicklung stattgefunden. Das Ziel der aktuellen Version war, eine neue für die Zukunft geltende Kompatibilitäts-Baseline zu definieren und sich dabei von einigen Altlasten zu trennen. Das bedeutet in diesem Fall das Entfernen von deprecated Features und APIs. Dies umfasst das Entfernen von deprecated Plug-ins, Klassen, Methoden und Kommandozeilen-Optionen. So ist zum Beispiel das code-quality-plugin durch die plugins checkstyle und codenarc ersetzt worden. Weiterhin gab es auch mehrere DSL-Änderungen. Als Beispiel sei hier die Änderung der Methode Project.file() erwähnt, die nun im Umgang mit Eingabewerten restriktiver ist und keine beliebigen Werte mehr zulässt.

Im Rahmen der neuen Version sind nicht nur deprecated Features und APIs weggefallen. Es wurden auch mehrere neue incubating Features aufgenommen. Dies sind Features, die frühzeitig in einer noch nicht finalen Version eingeführt werden, um möglichst zeitnah von den Entwicklern Feedback zu bekommen. Ein neues incubating Feature ist zum Beispiel eine neue API für das Auflösen von Source- und Javadoc-Artefakten.

Groovy 2.3 und Java 8

Eine der wichtigeren und weitreichenden Änderungen ist die im Rahmen des Major Releases durchgeführte Umstellung auf Groovy 2.3, der ersten Version mit offiziellem Java 8 Support. In den Release Notes wird diese Änderung unter der Kategorie „potential breaking changes“ geführt, da es sich bei dieser Umstellung um eine potentiell Konflikt-behaftete Änderung handelt. Das Update ist ein notwendiger Schritt im Hinblick auf den vom Gradle-Team angestrebten Support von Java 8.

Zwar besteht bei Groovy grundsätzlich eine Abwärtskompatibilität, jedoch ist dies bei der Version 2.3 nicht zu 100% der Fall, sodass mit der bis dato verwendeten Groovy-Version 1.8 ein Re-Kompilieren einiger Plugins nötig wird, damit diese auch mit Gradle 2.0 funktionieren. Weiterhin benötigt Groovy 2.3 mindestens ein JDK 6. Zwar wird offiziell nicht explizit angegeben, dass Groovy 2.3 kein JDK 5 unterstützt, jedoch wird auch darauf hingewiesen, dass die neue Groovy-Version mit dem JDK 5 nicht getestet wurde und Probleme bekannt sind. Damit gilt indirekt und irgendwie doch offiziell, dass das JDK 5 nicht mehr unterstützt wird. Diese Einschränkung überträgt sich entsprechend auf Gradle. So fällt bei Gradle zwar nun der Support für Java 5 weg, durch den Support von Java 8 wird dies jedoch mehr als nur kompensiert. Ein Update eventuell nicht mehr lauffähiger Plugins sollte in der Regel mit wenig Aufwand zu bewältigen sein. Builds, die bisher ohne die Ausgabe von deprecation warnings erfolgreich durchliefen, werden aller Voraussicht nach weiterhin erfolgreich durchlaufen.

Darüber hinaus wird das aktuelle Major Release noch durch viele weitere kleinere Änderungen geprägt, auf welche wir hier nicht weiter eingehen möchten und auf die Gradle Release Notes verweisen.

Was kommt nach Gradle 2.0 – ein Ausblick

Für die kommenden Monate haben die Gradle-Entwickler weitere neue Features und Verbesserungen angekündigt, die im gewohnten Rhythmus alle sechs bis acht Wochen im Rahmen von Minor Releases erscheinen sollen. Auch hier steht das Thema Performance wieder im Mittelpunkt. Parallelisierung, Caching und Konfigurationsphase sollen grundlegend überarbeitet und verbessert werden. Von den Performanceverbesserungen sollen insbesondere große Enterprise Builds mit vielen Subprojekten sowie die IDE Integration profitieren. Hier ist auch von einem dedizierten Gradleware Eclipse Plug-in die Rede.

Um die Erweiterbarkeit von Gradle zu verbessern, soll das zugrundeliegende Modell überarbeitet werden. Als Modell werden hier die verschiedenen Typen bezeichnet, die zusammen die Gradle DSL ergeben. Die Abwärtskompatibilität der angestrebten Änderungen zur aktuellen DSL wird dabei als wichtiges Ziel definiert, wobei auch die Migrationspfade so einfach wie möglich gestaltet werden sollen.

Des Weiteren wird an der Verbesserung der C/C++ Unterstützung gearbeitet. Interessant in diesem Zusammenhang ist die Tatsache, dass das Google Android Team an der Portierung des NDK von Make zu Gradle arbeitet. Hier eröffnet sich für Gradle die Chance, auch auf dem Markt nativer Build-Systeme weiter an Bedeutung zu gewinnen.

Fazit

Mit der neuen Version wurde der schon seit Längerem eingeschlagene Weg der kontinuierlichen Entwicklung und Verbesserung nicht nur konsequent weiter geführt, sondern darüber hinaus auch zu einem zwischenzeitlichen Abschluss geführt. Zwischenzeitlich, da mit der Version 2.0 von Gradle eine neue Kompatibilitäts-Baseline definiert wurde. Diese Baseline bildet die Basis für die weitere Entwicklung von Gradle und gibt der ohnehin großen und aktiven Community noch mehr Schwung, mit welchem das vorhandene Gradle-Momentum mehr als nur aufrecht erhalten werden kann.

Aufmacherbild: My second birthday. I am two years old now! Background with copyspace for the text. von Shutterstock / Urheberrecht: d13

Geschrieben von
Moritz Zimmer
Moritz Zimmer
Moritz Zimmer arbeitet als Teamleiter und Senior Software Engineer bei der Axel Springer ideas Engineering GmbH. Seine Schwerpunkte liegen unter anderem im Bereich des Build- und Content Managements sowie der Testautomatisierung. Kontakt: @Moritz_Zimmer
Marek Iwaszkiewicz
Marek Iwaszkiewicz
Marek Iwaszkiewicz ist für die directline AG als Senior Software Engineer tätig. Er beschäftigt sich seit Jahren mit Java EE Architekturen und Technologien. Seine Schwerpunkte liegen unter anderem im Bereich des Buildmanagements. Kontakt: @Marek_Iwaszkiewicz
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: