Fragen & Antworten zum Buildsystem Ant

Interaktiver Build-Vergleich: Ergebnisse – Ant

Jan Matèrne

In der finalen Runde des interaktiven Vergleichs zwischen den Buildsystemen Maven, Ant und Gradle beantwortet Jan Matèrne die Fragen aus der Community zum Apache-Projekt Ant. Dabei werden auch kritische Fragen zur Zukunftsfähigkeit der Ameise nicht ausgespart.

Hat Ant noch Zukunft?

Jan Matèrne: Die Community von Ant ist noch aktiv. Fragen und Diskussionen auf der Mailingliste finden statt und werden auch vom Entwicklerteam gut betreut.

Codeänderungen sind in der letzten Zeit im Ant Core selten gewesen (im Gegensatz zu Ivy und IvyDE). Ich kann allerdings nicht abschätzten, ob dies an mangelnden Ideen zu Neuerungen liegt oder an mangelnder Zeit. Ein fehlendes Interesse möchte ich aber aufgrund der regen Beteiligung der Entwickler in den Diskussionen ausschließen.

Ist Ant an einem Endpunkt angekommen?

Jan Matèrne: Meiner Meinung nach kann man von Release-Zyklen nicht ableiten, ob ein Projekt am Ende ist oder nicht, sondern lediglich, ob viel daran gearbeitet wird und eventuell auch, wie kompliziert die Veröffentlichung eines Releases ist. Bei Hudson beispielsweise purzelt quasi wöchentlich ein Release aus dem CI-Build heraus. Bei Apache sind dafür ein formaler Prozess und manuelle Schritte erforderlich.

Inhaltlich gab es in der Vergangenheit kaum Neuerungen, sondern primär Fehlerbehebungen.
Ob man dies als sterbend oder einfach nur als stabil ansehen möchte, will ich jedem selber überlassen.

An welchen großen Punkten werden bei ANT noch Änderungen/Erweiterungen zu erwarten sein?

Jan Matèrne: Wir haben keinen Releaseplan, in dem wir unsere Ideen fix machen und der Reihe nach abarbeiten (ansonsten wäre dieser Plan auch öffentlich zugänglich). Von da her sagt auch meine Glaskugel nichts über Überraschungen aus. Die Implementierung von Extension Points in Buildskripten ist beispielsweise recht zügig geschehen.

Ein Punkt, den ich selber noch adressieren wollte, ist die automatische Konfiguration von Tasks auf Basis von Property-Werten. Ein Prototyp hierfür befindet sich bereits in der Sandbox (vgl. auch meinen Artikel über das Ant-Ökosystem). Hier würde mich wieder das Feedback interessieren: Wird dies als sinnvoll angesehen? Da „Autoconf“ die Kapselung des gleichnamigen Unix-Tools nahe legt – welcher Name wird vorgeschlagen?

Wie sieht die Zukunft von Ant aus, wenn es denn eine gibt?

Jan Matèrne: Ich denke, die Stabilität ist das wichtigste Gut bei Ant. Daher wird das Hauptaugenmerk auf der Bereinigung von Fehlern liegen. Viele Projekte setzen seit Jahren Ant ein, und man würde viel Schaden anrichten, durch Änderungen diese Builds brechen zu lassen.
Jede Neuerung muss sich daher auf diese Tatsache hin überprüfen lassen – auch wenn aus heutiger Sicht einiges besser ginge.

Warum sollte ein neues Projekt noch auf Ant setzen?

Jan Matèrne: Jedes Werkzeug bedingt entsprechendes Know-How. Von da her ist jenes Werkzeug zur Umsetzung einer Aufgabe das beste, für das bereits entsprechendes Wissen vorhanden ist. Möchte man ein Repository aufsetzen und pflegen oder alles „wild“ aus dem Internet laden? Möchte man Dependency Management betreiben? Kennt man Groovy? Hat man die Ressourcen dafür?

Ich möchte nicht den Nutzen der einzelnen Disziplinen herunterspielen, aber man sollte im Auge behalten, was man sich alles mit einem Werkzeug anzieht. Ich persönlich möchte diesen Overhead nicht betreiben, um die vielen Beispiele meiner Schulungen durchzukompilieren (Sourcen in einem Verzeichnis, Binaries im anderen, JARs im lib-Verzeichnis).

Habe ich ein größeres Projekt, rate ich zu DM mit einem eigenen Repository. Und hier stellen sich mir dann die Fragen:

  • Wie gut kenne ich mich mit den einzelnen Buildwerkzeugen aus bzw. wie intensiv möchte/kann ich mich hineinarbeiten?
  • In wieweit entspricht der vom Werkzeug prädestinierte Weg meinem eigenen?
Geschrieben von
Jan Matèrne
Kommentare

Schreibe einen Kommentar

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