Wie buildet ihr eure PlugIns?

[Wildcard]

Hi,

wir überlegen derzeit ein neues build system (zunächst für ein einziges Eclipse basiertes Projekt, bei Erfolg später evtl. auch reguläre J2EE Projekte) aufzusetzen.
Da den PlugIn Entwicklern unter euch wohl hinreichend die Schwierigkeiten mit konventionellen PDE Builds in komplexen Build Systemen bekannt sind, würde mich interessieren, was habt ihr bereits versucht, was hat funktioniert, was hat nicht funktioniert?

In das CI System sollen auch Unit-,Plugin-Test (inkl Oberflächentests der PlugIns), Metriken, Code Coverage, Benchmarks,... angeschlossen werden.
Die Versionsverwaltung ist CVS, die zukünftige Lösung sollte aber natürlich auch mit SVN funktionieren.

Nun stellt sich die Frage nach der richtigen Kombination der einzelnen Softwarebausteine.
Meine initiale Idee wäre Hudson als CI Server und für Build,Test,Deploy,... Buckminster über ein Ant Script aufrufen, aber wie bindet man die Tests und die Metriken sinnvoll in diesen Prozess ein?

Wie sind eure Erfahrungen mit Maven für diesen Anwendungsfall?
Wie führt ihr die PlugIn Tests aus?
Wie sieht bei euch die Infrastruktur im allgemeinen aus und wie sind eure Erfahrungen damit?

Gruß und Dank,
Wildcard

 

[Vayu]

In meiner alten Firma haben wir Ant hergenommen, um unsere plugins zu bauen und (ich weiss nimmer genau wie es gemacht wurde) Teile von eclipse hergenommen, um die JUnit tests laufen zu lassen. Atlassian Clover haben wir als Code Coverage Tool hergenommen, lässt sich wunderbar über Ant einbinden. Kost zwar Geld, ist aber wirklich mächtig. SVN und CVS hatten wir beides drin, frag nicht wieso ^^

GUI tests haben wir ausgelagert, dafür hatten wir n ecilpse plugin geschrieben, mit dem die durchgeführt wurden)

Aber der Rest lief unter Linux mit ant auf der Kommandozeile.

 

[Ebenius]

Unser Hauptprodukt besteht aus circa 50 Modulen. Die meisten davon sind Java ein paar C, C++, TCL, bash-Skripte, etc. Daher wird bei uns alles mit make/GNUmake gebaut. In manchen Projekten ruft das Makefile ANT auf. Wenn Du reine Java-Anwendungen baust, würde ich davon abraten. Wenn Du, wie wir, auch andere Technologien einsetzt, ist das gar nicht mal so schlecht.

Grüße, Ebenius

 

[Vayu]

so wars bei uns am anfang auch, make mit ant verbandelt, das wurde aber bei der grösse echt hässlich. Unser RCP besteht aus ca. 30 plugins (nur Java) mit nochmal ca. der hälfte an test plugins.

da haben wir dann mal in den "sauren" apfel gebissen und komplett auf ant umgestellt. Aber es hat sich gelohnt.

 

[WildcardGast]

Erstmal danke für die Antworten.
Auf ANT setzen wir schon lange und es sind auch reine Java Projekte, daran soll es also nicht scheitern.
Was mich derzeit stört ist der extrem hohe ANT-Script Aufwand für den PDE Build und die Tests, ausserdem suche ich nach einer komfortablen Möglichkeit die Ergebnisse an die CI Software weiterzureichen.
Nach Möglichkeit würde ich gerne vermeiden ein Build Eclipse zu pflegen, mit PDE zu builden, das Ergebnis in ein Test/Metrik Eclipse zu packen und diese Instanz dann noch n mal zu starten um alle Tests und Metriken durchlaufen zu lassen.
Idealerweise sollten die PlugIn Tests zB self hosted sein, wie es beim PDE Build ja auch möglich ist, aber ich versuche mir die hässlichen PDE Scripte (customTargets.xml, test.xml,...) zu ersparen und damit die Integration neuer Projekte möglichst einfach zu gestallten.
Buckminster geht da IMO den richtigen Weg, aber es funktioniert derzeit leider noch nicht so wie ich es gerne hätte. :-/

 

[Wildcard]

Also mal ein Update mit den bisherigen Ergebnissen.

Derzeit sieht der Plan folgendermaßen aus:
Das CI System wird Hudson, den großteil der Arbeit mit den Bundles möchte ich allerdings in Buckminster auslagern.
Dazu habe ich ein Hudson PlugIn geschrieben um einen neuen Builder ins System zu integrieren (Buckminster).
Im Job das den Buckminster Builder verwendet werden dann die Commands für Headless Buckminster in Form einer Liste eingetragen, also zB

resolve my.product.cquery
perform build.site

Das Hudson PlugIn setzt alle notwendigen Parameter für den Buckminster Aufruf (commands, workspace, buckminster.output.root,...) und startet den Build.
Die PlugIn Tests werden im Anschluss an den Build mit ANT gestartet. Als Framework möchte ich dafür TPTP verwenden, da es die Tests self hosted durchführen kann, und der Workspace dank Buckminster ja bereits vollständig während des builds materialisiert wurde.

Sollte sich dieses System bewähren, werde ich einen ausführlicheren Bericht schreiben und das PlugIn natürlich dem Hudson Projekt anbieten.

Was noch fehlt ist das Einbinden von Metriken und publishen von Reports, aber erst mal sehen ob der Rest auch wirklich so tut wie er soll

 

[Wildcard]

--Update--

Das Hudson Plugin für die Buckminster Integration ist bald fertig.
Derzeit möglich:
-beliebige viele Eclipse Instanzen in der Hudson Konfigurationsseite anlegen
-zusätzliche startup Parameter pro Instanz angeben
-buckminster builder im job verwenden
-eclipse instanz auswählen
-liste mit commands eintragen
-bei perform commands wird automatisch das property buckminster.output.root auf das Hudson Artifacts Directory gesetzt
-Die Ausgabe wird an den BuildListener zurückgegeben
-der Workspace wird auf den Hudson Workspace gesetzt
Dadurch kann man wahlweise das check-out von einem Hudson SCM Plugin erledigen lassen, oder alles von Buckminster resolven lassen (oder beides)


Noch offene Punkte für den automatischen Build
-Dem Sonar Plugin beibringen das es mehrere Projekte pro Job analysieren muss
-Dem Warnings PlugIn den Buckminster Output übersetzen
-Einen neuen Ansatz für automatisierte PlugIn Unit Tests finden, da sich TPTP auf Linux Systemen als Totalausfall erweist :?