Fragen & Antworten zum Buildsystem Gradle

Interaktiver Build-Vergleich: Ergebnisse – Gradle

Im Rahmen des interaktiven Vergleichs der Build-Systeme Maven, Ant und Gradle beantwortet Hans Dockter Fragen aus der Community zu Gradle.

Martin Wildam: Was ist der große Vorteil von Gradle im Vergleich zu Ant und ab welchen Projektgrößen erreichen die Vorteile einen entscheidenden Anteil?

Hans Dockter: Ein großer Vorteil ist die in der Regel sehr viel bessere Wartbarkeit. Das ist ein Hauptgrund für viele Enterprise-Ant-Projekte, zu Gradle zu wechseln. Deren Wartbarkeit war so problematisch, das sich kaum noch einer getraut hat, den Build anzufassen, geschweige denn ambitionierte neue Automatisierungs-Requirements zu implementieren.

Ein weiterer kritischer Aspekt ist oft Performance. Gradle bietet inkrementelle Builds und parallele Test-Ausführung und punktet hier gegenüber Ant. In diesem Bereich haben wir zudem noch viel vor (z.B. parallele und verteilte Builds).

Ein anderer wichtiger Punkt ist die Schwierigkeit mit Ant, Projekt-Abhängigkeiten zu modellieren. Selbst mit Ivy ist das nicht besonders leistungsstark. Das ist auch ein Gebiet, wo Gradle extrem viel bietet.

Ich denke, ich belasse es mal bei diesen Punkten.

Projektgröße ist sicherlich ein wichtiger Parameter. Aber ein noch wichtigerer – der zudem oft mit der Projektgröße korreliert – ist die Komplexität der Automatisierungsanforderungen.

Nehmen Sie zum Beispiel das Gradle-Projekt selber. Es ist nach Enterprise-Maßstäben sicherlich ein kleines Projekt. Aber wir sind sehr ambitioniert mit der Automatisierung (Userguide-Validierung, Release Management, Website Updates, …). Den derzeitigen Gradle Build mit Maven oder Ant zu schreiben, wäre nicht unbedingt ein Spaß.

Die klassische Single-Project Open Source Library, wo nur die Javadoc und das Jar der Output sind, ist sicherlich ein Beispiel, bei dem das Build-System nicht so wichtig ist. Je mehr es darüber hinausgeht, desto mehr merkt man den Unterschied. Die Probleme einer nicht gut funktionierenden Automatisierung sind aber zweifelsohne in Projekten mit vielen Entwicklern am schmerzhaftesten und erreichen leicht einen Punkt, wo die ganze Software-Entwicklung nicht mehr funktioniert. Das konnten wir bei einigen unserer Kunden, die mehrere hundert Entwickler im Projekt haben, selber erfahren.

Zusammengefasst denke ich, dass sich ein Wechsel auf Gradle für die meisten Enterprise-Projekte bald bezahlt macht – ob 5 oder 200 Entwickler.

Carsten Ziegeler: Warum sollte ich mir Gradle anschauen, insbesondere da Apache Maven und Apache Ant eigentlich schon alle Bedürfnisse abdecken?

Hans Dockter: In dem ersten JAXenter-Interview bin ich ja ausführlich darauf eingegangen, wo ich die Vorteile von Gradle sehe. Mehr kann ich an dieser Stelle nicht hinzuzufügen.

Wenn alle ihre Bedürfnisse abgedeckt sind, gibt es keinen Grund zu wechseln. Ich würde aber empfehlen, ihre Bedürfnisse abzugleichen mit den Standards, die zum Beispiel im Buch ‚Continuous Delivery‘ von Jez Humble vorgeschlagen werden.

Alexander Culum: Bestehende Ant-Projekte auf Maven zu migrieren ist unter Umständen sehr teuer, deshalb ist es fraglich und abhängig vom Einzelfall, ob sich dies lohnt. Ab wann lohnt sich eine Migration von Maven- (oder Ant-)Projekten zu Gradle?

Hans Dockter: Build-Migration ist ein sehr wichtiges und oft unternehmens-kritisches Unterfangen. Gradle hat hier einiges zu bieten, um die Migration weniger teuer zu machen. Das hat sich in der Praxis, bei kleinen und sehr großen Migrationen, bewährt.

Migration von Ant-Builds:

  • Bitte Baby-Steps!
  • Die Projektstruktur im ersten Schritt unverändert lassen. Dann ist kein Fork nötig, da Gradle sich an alle Projekt-Strukturen anpassen kann. Selbst wenn man vor hat, die Projektstruktur zu ändern, sollte man das nicht tun, solange der Ant Build produktiv ist.
  • Mit dem Ant-Import, den Gradle anbietet, kann man Ant-Builds auch partiell zu Gradle migrieren.
  • Wir empfehlen, im Gradle Build Tests zu schreiben, die den relevanten Build-Output des Ant-Builds mit dem des Gradle-Build vergleichen (Jars, Zips, ausgeführte Tests, Javadoc, …). Ein Produktiv-Build verändern sich oft ständig. Mit den Tests weiß man immer, ob die Builds in sync sind.
  • Wenn der Gradle-Build produktiv ist, könnte dann auch ein Refactoring der Projektstruktur beginnen.

Migration von Maven-Builds:

  • Normalerweise sehr einfach. Es gibt sogar einen Konverter.
  • Das einzige, was noch nicht geht, ist das Aufrufen von Maven-Plug-ins aus Gradle (wir arbeiten daran). Das heißt auch, dass Custom-Maven Plug-ins nach Gradle portiert werden müssen. Aber auch das ist meist unkompliziert.

Jens Wagner: Mich würde interessieren, was es mit dem Groovy-DSL-Ansatz auf sich hat: Warum Groovy? Wie gut muss ich in Gradle mit Groovy vertraut sein?

Hans Dockter: Das ist eine gute Frage. Die Tatsache, dass Gradle Groovy und nicht XML verwendet, ist unserer Meinung nach kein wesentliches Unterscheidungsmerkmal zwischen Gradle, Ant und Maven. Wir glauben, dass es möglich wäre, ein vernünftiges Build-System auch auf XML-Basis zu schreiben. Gleichzeitig ist es auch ein Leichtes, irgendeine Groovy-DSL für Ant und Maven zu schaffen, wie das schon experimentell bei Polyglot Maven geschehen ist.

Die Dinge, die wir bei Ant und Maven nicht so gut finden, liegen nicht am XML-Ansatz. Das Spring-Framework zeigt, wie man auch mit XML eine flexible und reiche DSL bauen kann.

Nichtsdestotrotz halten wir aber für die Build-Domäne eine Groovy-DSL für viel besser geeignet als eine XML-DSL. Gradle verfolgt einen sehr deklarativen Ansatz. Aber immer mal wieder macht es Sinn, kurze imperative Statements in den Build einzubauen. Sei es ein Boolescher Ausdruck oder eine If-Abfrage. Es ist ja nicht zufällig, dass Ant oder Maven ihre XML-DSL aufblasen mussten, um derartiges zu modellieren. Ich denke hier an Maven Profiles, Ant-contrib oder Ant Skip properties. Mit Groovy brauche ich dazu nicht die DSL aufzublasen. Jeder User weiß auch direkt, was zu tun ist, vorausgesetzt man ist vertraut mit Java. Und die Java If-Abfrage ist um ein vielfaches leistungsfähiger als ihre Maven- oder Ant-Äquivalente. Das ist nur ein Beispiel.

Wir werden auch öfters gefragt, warum wir keine Java-DSL verwenden. Die dynamische Natur von Groovy macht es sehr einfach, die Gradle-DSL zu erweitern. Das wäre mit einer Java-DSL nicht so einfach möglich. Auch hat Groovy sehr mächtige Funktionen, um z. B. mit Input/Output oder Collections zu arbeiten. Gerade in unserer Domäne sind diese Dinge sehr hilfreich. Gleichzeitig macht die Nähe von Groovy zu Java es sehr einfach für Java-Entwickler, Gradle zu benutzen. Man braucht keine besonderen Groovy-Kenntnisse, um mit Gradle zu starten. In den Gradle-Trainings geben wir eine 15-minütige Einführung in Groovy, dann geht es mit Gradle los. Schaden tun Groovy-Kenntnisse aber natürlich dennoch nicht. Ein weiterer Vorteil ist, dass sie mit Groovy etwas lernen, was auch jenseits von Gradle sehr nützlich sein kann. Das ist bei Ant-contrib, Macrodefs, Mixins, Profiles, etc. nicht der Fall.

Kommentare

Schreibe einen Kommentar

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