- JAXenter

azgard: Ich muss leider feststellen, dass es bezüglich Anzahl der Plugins sehr dürftig aussieht. Wie steht es denn um die Unterstützung für EAR-,RAR-Builds etc. ?

Hans Dockter: Sie sprechen einen wichtigen Punkt an. Das Gradle-Plug-in-Ökosystem ist noch nicht voll entwickelt. Aber es tut sich gerade sehr viel. Für 1.0 planen wir auch ein Gradle Plug-in-Portal und eine bessere Unterstützung für Plug-in-Autoren.

Sie haben bei Gradle immer auch alle Ant-Tasks zur Verfügung. Diese sehen wir als integralen Bestandteil von Gradle. Selbst wenn es noch kein natives Gradle-Plug-in für eine bestimmte Aufgabe gibt, kann man das damit sehr leicht modellieren.

Markus Stäuble: Besteht mit Gradle nicht wieder das Problem, dass zuviel im Build programmiert wird?

Hans Dockter: Lassen Sie mich es so beantworten. Es besteht natürlich die Gefahr, dass schlechter Code produziert wird. Wie überall. Und zuviel Programmierung im Build ist schlechter Code.

Gradle ist ein deklaratives Build-System. Sehr viel mehr als Maven. Das erreichen wir dadurch, dass die Gradle DSL erweiterbar ist. Mit Hilfe dieser Erweiterbarkeit lässt sich das Imperative sehr gut von dem Deklarativen trennen. Letzteres ist eines der Haupt-Prinzipien für einen guten Build. Wenn ich einen komplexen Custom-Workflow bei Maven habe, für den ich z. B. acht Plug-ins irgendwo in den Lifecycle integrieren muss, ist das auch eine Art von Low-Level-Programmierung, die den Build schwer zu lesen und zu warten macht. Mit Gradle könnten sie das einfach mit einem deklarativen Element abstrahieren.

Gradle bietet noch viele andere Möglichkeiten, die Les- und Wartbarkeit zu erhöhen. Les- und Wartbarkeit ist eine besondere Stärke von Gradle.

René Eggenschwiler, Florian Huonder, Ylli Sylejmani: Wie sieht es mit der Interoperabilität zwischen Gradle, Maven und Ant aus? Ist eine Integration (Ant-Maven, Maven-Gradle, Ant-Gradle) untereinander möglich?

Hans Dockter: Ich würde sagen: sehr gut. Gradle ist ein Build-Tool, aber auch ein Build-Integration-Tool. Die Build-Landschaft ist heterogen und wird heterogen bleiben, allein schon aus Legacy-Gründen. Darauf ist Gradle eingerichtet.

Integration mit Ant:

  • Verwenden aller Ant-Tasks inklusive Custom Ant Tasks
  • Import von Ant-Builds
  • Integration mit Ivy-Repositories (lesen und publizieren)

Integration mit Maven:

  • Import von Maven-Builds
  • Konvertierung von Maven-Builds
  • Integration mit Maven-Repositories (lesen und publizieren)
  • todo: Aufrufen von Maven-Plug-ins von Gradle aus
  • todo: Die Maven-Integration Features gibt es zurzeit nur als externes Plug-in. Das wird in Gradle 1.0-milestone-1 integriert werden.

René Eggenschwiler, Florian Huonder, Ylli Sylejmani: Mit welchem Build-Tool wird Gradle entwickelt?

Hans Dockter: Natürlich mit Gradle 🙂 Außer in den ersten Lebenswochen des Projektes, wo wir einen Ant-Build hatten.

Markus Stäuble: Wann wird es eine Version 1.0 geben?

Hans Dockter: Gute Frage :). Mitte Februar wird der 1.0-milestone-1 erscheinen. Alle 4-6 Wochen wird es ein weiteres Milestone-Release geben. Wann es den ersten Release-Kandidaten geben wird, ist noch nicht klar. Es hat für uns aber hohe Priorität, diesen Punkt bald zu erreichen.

Das sollte aber niemanden davon abhalten, Gradle schon zu benutzen. Gradle 0.9 wird in sehr großen Enterprise-Builds produktiv eingesetzt (z.B. > 10M LOC, 200 Entwickler, 600 Module), wie auch von Hibernate und vielen SpringSource-Projekten. Wir werden bei der Evolution nach 1.0 sehr sorgfältig und vorsichtig vorgehen.

JAXenter: Vielen Dank für die Beantwortung der Fragen!

Hans Dockter ist der Gründer und Leiter von Gradle, sowie der Geschäftsführer der Gradle GmbH. Er hat 12 Jahre Erfahrung als Software-Entwickler, Projektleiter, Architekt, Trainer und Mentor. In grauer Vorzeit war er auch Committer für das JBoss-Projekt und schuf die JBoss-IDE.
Kommentare

Schreibe einen Kommentar

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