Kritik am Artikel "Ein "Einstieg in Gradle für Java-Entwickler"

[mgruebsch]

Zum Artikel möchte ich zwei Kritikpunkte anmerken:

1. In jeder Ausgabe des Java-Magazins lernen wir, dass zuerst Zielbeschreibungen formuliert und Anforderungen erhoben werden müssen. Warum wir aber statt Make, Ant und Maven nun Gradle benutzen sollten, bleibt der Artikel schuldig.
2. Build-Tools wechseln einander in immer schnellerer Folge ab. Statt ein neues Build-Tool zu entwickeln, wäre es günstiger, das alte besser verstehen zu lernen oder es zu verbessern. Damit spart man nicht nur eigenen Ressourcen, sondern auch die der Projektteams, die auf neue Build-Konfigurationen umsteigen müssen.

Make hat mehrere Jahrzehnte auf dem Buckel. Es ist deklarativ und folgt dem Grundsatz "convention over configuration". Dann wurde Ant eingeführt, weil XML am Maximum des hype cycles angelangt war und Entwickler das deklarative Programmierparadigma nicht mehr verstanden. Später folgte Maven, erhob "convention over configuration" zum Non Plus Ultra und führte das Deklarative durch die Hintertür ein. Maven 3 verabschiedet sich von XML ...

Und nun Gradle? - warum eigentlich? Die Antwort auf diese Frage hätte am Anfang des Artikels stehen müssen.

Beste Grüße

[etienne]

Guten Tag

Vielen Dank fuer Ihr Feedback, zu welchem ich gerne Stellung nehme.

1) Die Gradle-Serie bietet einen Einstieg in Gradle, inkl. Beispielen, wichtigen Grundkonzepten und Enterprise-Anforderungen. Dies wird zu Beginn des ersten Artikels auch deutlich so formuliert. Die Serie ist kein Vergleich verschiedener Build-Tools und sie kommuniziert auch nicht, dass man statt Ant oder Maven nun Gradle benutzen sollte. Diese Entscheidung hängt von vielen Faktoren ab und wird dem Leser ueberlassen. Am Ende der Serie wird es dem Leser aber einfacher fallen, eine fundierte Entscheidung fuer oder gegen Gradle zu treffen.

Im Anschluss an die Serie waere es sicher interessant, einen Artikel zu publizieren, der die verschiedenen Build-Tools miteinander vergleicht.

2) Niemand wird zum Umstieg auf ein neues Build-Tool gezwungen. Die Entscheidung liegt beim Projekt-Verantwortlichen. Tatsache ist aber, dass sich die Build-Anforderungen seit der Geburt von Ant und Maven stark veraendert haben, sprich viel komplexer wurden, und dass viele Projekte ein Build-Tool benoetigen, welches die heutigen komplexen Anforderungen wartbar und erweiterbar erfuellen kann. Die steigende Popularitaet von Gradle zeigt, dass offensichtlich Bedarf fuer neue innovative Build-Tools vorhanden ist.

Schoen an dem Java-Oekosystem finde ich, dass man sehr oft die Wahl hat zwischen verschiedenen Technologien, so auch bei den Build-Tools. Die Wahl muss und darf jeder selbst treffen.

Freundliche Gruesse, Etienne Studer

[hansd]

Einen Vergleich der Konzepte von Gradle mit denen von Ant und Maven können sie hier finden: http://gradle.org/other-resources/ja...radle-2010.pdf

Viele Grüße

- Hans Dockter

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz

[mgruebsch]

Ich verstehe Ihre Punkte und ich will auch nicht die Entwicklung eines Build-Tools an sich kritisieren.

Allerdings bin ich der Meinung, dass Build-Tools in eine andere Kategorie als die diversen Libraries des Java-Öko-Systems gehören. Inwiefern die Umstellung des Build-Prozesses einer zentralen Bibliothek wie bspw. Hibernate auf Gradle dauerhaft ohne Auswirkungen auf den Maven-Build-Prozess abhängiger Projekte ist, bleibt abzuwarten. Zudem erhöht jedes neue Build-Tool die Diversifizierung im Java-Öko-Systems. Für mich scheint es wahrscheinlich, dass deswegen irgendwann Inkompatibilitäten auftreten werden und man entweder zu einem unverhältnismäßig hohen Integrationsaufwand oder selbst zur Umstellung gezwungen ist.

Ich bin daher der Meinung, dass ein neues Build-Tool sich mit sehr guten Argumenten rechtfertigen muss. Gefragt ist nicht ein a posteriori Vergleich der Build-Tools, sondern eine a priori Rechtfertigung des sich über kurz oder lang für alle abzeichenden Aufwands.

Beste Grüße