Interview mit Hans Dockter zum Release von Gradle 1.0

Das ist neu in Gradle 1.0

Claudia Fröhling

Das populäre Build-System Gradle ist letzte Woche in seiner ersten Major-Version erschienen. Grund genug, uns mit Gradle-Projektleiter Hans Dockter über das Release und dessen Highlights zu unterhalten.

JAXenter: Hans, erstmal herzlichen Glückwunsch zum ersten Major Release. Wie lange habt ihr an Gradle 1.0 gearbeitet?

Hans Dockter: Vielen Dank. Wie du dir denken kannst, sind wir sehr froh diesen Schritt nun gemacht zu haben. Der 1.0-milestone-1 ist vom Februar 2011. Insofern stecken da jetzt fast 1.5 Jahre Arbeit drin. Ich möchte mich bei allen Unterstützern bedanken. Ohne den Input und die Überzeugungskraft von Leuten wie Dierk König, Graeme Rocher, Steve Ebersole oder Chris Beams wäre Gradle nicht da, wo es jetzt ist. Das gibt uns auch viel Antrieb unsere Technologie weiter zu entwickeln. Continuous Delivery ist eine der großen Baustellen in der gegenwärtigen Software-Entwicklungslandschaft. Wir wollen unseren Teil dazu beitragen, die Situation zu verbessern. Sowohl konzeptuell über neue Patterns und Konzepte als auch mit coolen neuen Gradle Features.

JAXenter: Neu in dieser Version ist unter anderem das Gradle Tooling API. Was kann man sich darunter vorstellen?

Hans Dockter: Hauptfokus ist der Gradle Support in IDEs. Die Konzepte der Tooling API sind in Zusammenarbeit mit dem SpringSource STS Team entwickelt worden, die auch das Gradle Eclipse Plugin schreiben. Wir wollen es so einfach wie möglich machen, Gradle von anderen Tools aus zu benutzen. Die Tooling API ist eine stabile Schnittstelle zum Gradle Buildsystem, die für einen langen Zeitraum sowohl vorwärts als auch rückwärts kompatibel zu verschiedenen Gradle Versionen ist. Dadurch entfällt z.B. das Problem, das Gradle Eclipse Plugin unter Umständen updaten zu müssen, wenn man mit einer neuen Version von Gradle aus Eclipse heraus bauen will. Die Tooling API kümmert sich auch darum in Zusammenarbeit mit dem Gradle Wrapper, die benötigte Gradle Version automatisch runter zu laden. In der Zukunft wird sie den IDEs auch helfen einen Content Assist anzubieten. Es gibt noch einige weitere Features. Wer Interesse hat, kann die im Userguide nachschlagen.

JAXenter: In Sachen Dependency-Management habt ihr euch von Ivy verabschiedet. Wie kam es dazu?

Hans Dockter: Zuerst mal möchte ich sagen, dass uns Ivy lange Zeit gute Dienste geleistet hat. Dafür gilt der Ivy Community unser herzlicher Dank. Ivy hat auch sehr leistungsfähige Konzepte, die über die Standards der Maven Pom hinausgehen. Diese Ideen sind von uns aufgegriffen worden und werden weiterentwickelt. Zudem werden wir auch in Zukunft das Ivy Dependency Format, neben dem Pom Format, unterstützen.

Warum haben wir uns nun von Ivy verabschiedet? Der Fokus von Ivy und seinen Usern gilt dem eigenen Ivy Dependency Format. Ivy hat zwar einen Maven Pom Kompatibilitätsmodus, der ist aber mit Problemen behaftet. Die Performance ist nicht berauschend, unter anderem dadurch, dass es für jeden Library Download eine Vielzahl von überflüssigen Head-Requests gibt. Das Verarbeiten von Maven Snapshots ist auch problematisch. Für uns war das ein großes Problem, da ein großer Teil der Gradle User, Maven Poms verwendet. Zuerst haben wir es hier mit Workarounds versucht. Letzten Endes war uns dann aber irgendwann klar, dass wir für eine gute Lösung was Eigenes bauen müssen. Das war auch schmerzhaft für uns. Wir haben diese Entscheidung erst nach Milestone-3 getroffen. Das hat die Auslieferung von 1.0 erheblich in die Länge gezogen hat. Wir sind aber jetzt überglücklich darüber. Unseren Usern haben nun ein zuverlässiges und das unserer Meinung nach leistungsfähigste Dependency Management in der Java Welt. Auf dieser Basis können wir nun auch unsere weiteren Innovationen in diesem Gebiet schnell vorantreiben. Unter anderem ein Dependency Management für C++ Projekte.

Geschrieben von
Claudia Fröhling
Kommentare

Schreibe einen Kommentar

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