Hudson bei Eclipse, Jenkins bei Apache?

Hartmut Schlosser

Die Hudson-Community hat sich durch das Fehlen einer adäquaten Architektur-Dokumentation und durch die Art, wie bisher Entscheidungen getroffen wurden, in eine Abhängigkeit von einer einzigen Person begeben, schreibt Sonatype-Gründer Jason van Zyl auf seinem Blog. Gemeint ist Hudson-Erfinder Kohsuke Kawaguchi, der das Continuous-Integration-Projekt nach Trademark-Streitigkeiten mit Oracle unter dem neuen Namen Jenkins weiterführt.

Van Zyl zeichnet ein durchaus negatives Bild vom aktuellen Zustand der Hudson-Codebasis, die es schwierig für Drittparteien mache, an einer Verbesserung des Hudson-Kerns mitzuwirken.
Die Hudson-WAR-Distribution enthalte über 100 Abhängigkeiten, die schwer zu handhaben seien, veraltete Technologien wie das User Interface Tool Jelly seien integriert, die Testinfrastruktur ließe zu wünschen übrig und ungeklärte Lizenzfragen erschwerten den Einsatz in Unternehmen.

Sonatype wolle sich deshalb u.a. der Verbesserung der Test-Infrastruktur widmen, die Integrationen in Eclipse und NetBeans vorantreiben sowie den Support für Maven, JSR330 und JAX-RS erweitern.

Kohsuke Kawaguchi reagiert im Kommentar-Thread. Zunächst sei es allen anderen am Hudson-Kern beteiligten Entwicklern gegenüber nicht fair, ihn als alleinigen Urheber von Hudson zu bezeichnen. Außerdem seien Architekturentscheidungen immer unter Berücksichtigung des bestehenden Ökosystems getroffen worden, das man nicht durch radikale Veränderungen gefährden wolle.

Overall I think I’ve made good enough calls, or else we aren’t seeing 300+ plugins developed today. Kohsuke Kawaguchi

Eclipse, Apache, Oracle, SFC, Jenkins Foundation?

In den Kommentaren ist auch zu lesen, dass Jason van Zyl zur Lösung der Urheberrechtsfragen die Übertragung von Hudson an die Eclipse Foundation in Erwägung gezogen hatte, die für ihre strikten Anforderungen an einwandfrei offengelegte Lizenz-Bedingungen bekannt ist.

I believe the only viable paths are to move Hudson to the Eclipse Foundation or work with Oracle. Jason van Zyl

Gleichzeitig ist in einem Meeting der Jenkins-Gruppe eine Diskussion in Gang gekommen, das Jenkins-Projekt unter dem Dach der Apache Foundation weiter zu entwickeln. Ursprünglich vorgesehen war eine Anbindung an das SFC (Software Freedom Conservancy). Laut Meeting-Protokoll hat Andrew Bayer nun allerdings Zweifel angemeldet, ob dies gelingen könne. Zum einen sei es dem SFC nicht daran gelegen, sich mit Oracle anzulegen. Zum anderen sei das SFC bereits mit einer überaus großen Anzahl von Projekten betraut. Während der SFC immer noch die angestrebte Lösung darstelle, solle man sich deshalb auch über Alternativen Gedanken machen.

I think it’s worth at least talking with Apache as to whether there’s any chance we can pair up. Andrew Bayer

Hudson bei Eclipse und Jenkins bei Apache?

Hudson bei Eclipse und Jenkins bei Apache? Dass es so kommen wird, scheint unwahrscheinlich. Die beteiligten Diskussionspartner äußern sich selbst skeptisch über diese Perspektive:

Auf der Hudson-Seite berichtet Jason van Zyl, Oracle sei nicht auf seinen Vorschlag eingegangen:

Brian and I talked with talked with Kohsuke about moving the project to the Eclipse Foundation. Oracle was not interested in moving it to Eclipse at that time, and I understand that position. Jason van Zyl

Auf der Jenkins-Seite gibt Andrew Bayer zu bedenken, dass sich durch einen Umzug nach Apache neue Copyright-Probleme mit Oracle ergeben könnten.

ASF is a pipe dream of mine here [.] But from what I know, the problem is that we can’t get copyright reassignment of the existing code to Apache, nor can we relicense. Andrew Bayer

Die Fantasie beflügelt hat die Apache-Perspektive die Jenkins-Community allemal. Zahlreiche Diskussionsbeiträge hat ein entsprechender Eintrag auf der Jenkins-Mailing-Liste erhalten.

I think hosting Jenkins as an ASF project would add even more creditability to Jenkins. I don’t think existing licenses prevent such a movement. What do you think? Michael Hüttermann

Es bleibt abzuwarten, unter welches Dach sich Jenkins letztlich begeben wird – bzw. kann. Sollte weder das SFC noch die Apache-Lösung für Jenkins möglich sein, wurde im Jenkins-Meeting übrigens die Gründung einer eigenen Jenkins Foundation vorgeschlagen.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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