Hudson/Buckminster: Verschiedene Fragen

[Antimon]

Hallo zusammen,

mittlerweile versuche ich mich seit einigen Wochen durch das Dickicht der Dokus zu schlagen, um meine RCP-Applikation vernünftig mit Buckminster und Hudson bauen lassen zu können - dabei treffe ich aber leider immer wieder auf Hürden, die vermutlich mit etwas Hintergrundwissen leicht zu überwinden sind, aber das habe ich leider noch nicht Deswegen hoffe ich auf Eure Tips.

Um was es grob geht: Eine RCP-Applikation die aus einigen Plugins besteht, soll es in mehreren Varianten geben, die verschiedene Zielgruppen anspricht. Das heisst beispielsweise gibt es Variante 1 die aus Plugin A und B besteht, dann gibt es noch Variante 2, die aus Plugin A und C besteht. Beide Varianten sollten als eigenständige Pakete für Windows, Linux und MacOS erstellt werden.

Dazu die erste Frage: Damit die Anwendungen sich später einmal selbst updaten können, soll es eine Update-Site geben, diese kann ja von beiden Varianten ("Distributionen") verwendet werden und soll alle Plugins enthalten. Dafür ist es vermutlich am besten, ein eigenes Feature mit allen verfügbaren Plugins zu erstellen - richtig?

Wenn ich das nun richtig verstanden habe, baut Buckminster zuerst einmal aus allen Plugins eine Update Site zusammen und erst danach werden die plattformspezifischen Applikationen gebaut. Würde es dann für mich Sinn machen, ein Buckminster-Projekt in Hudson zu erstellen, dass diese Update-Site erstellt? Und sobald diese vorhanden ist können die Distributionen davon gebaut werden?

Falls meine Denkweise bis hierher stimmt - wie baut man so einen Job in Hudson am besten?
Im SVN sind alle Plugins unter <programm>/plugins/org.xyz.../trunk/ und die features unter <programm>/features/org.xyz.../trunk/
Welche Ordnerstruktur erwartet Buckminster und wie bringe ich die am besten hin? Im Hudson jedes Plugin einzeln auschecken und im Workspace ohne das Verzeichnis trunk speichern? Oder das Verzeichnis "<programm>", welches alle Plugins und Features (und noch andere Dinge) enthält auschecken und entsprechend mappen?
Was würdet Ihr mir empfehlen?

Freue mich schon auf Eure Tips und Anregungen!

 

[Wildcard]

Wenn ich das nun richtig verstanden habe, baut Buckminster zuerst einmal aus allen Plugins eine Update Site zusammen und erst danach werden die plattformspezifischen Applikationen gebaut. Würde es dann für mich Sinn machen, ein Buckminster-Projekt in Hudson zu erstellen, dass diese Update-Site erstellt? Und sobald diese vorhanden ist können die Distributionen davon gebaut werden?

Buckminster baut die RCP erstmal gar nicht, sondern nur die Update Site. Aus der Update Site ein Produkt zu bauen übernimmt die p2 Director Application. Den Director kann man per Shellscript oder Ant Script ansteuern. Hat man ein solches Ant Script, kann man den Director dann doch wieder in Buckminster integrieren indem man einen Ant Actor verwendet, der dann das script ausführt.

Mehrere solcher Zips baut man in Hudson nun zum Beispiel mit einem Multikonfigurationsprojekt.
Wie das funktioniert ist auf dieser Wiki Seite erklärt:
Building an RCP application with hudson (Buckminster) - Eclipsepedia
Den Teil mit der Target Platform kannst du dir mittlerweile sparen, wenn du ein Target Definition File verwendest.

Alternativ dazu kannst du auch einen Job bauen der die Update Site baut, dann ein Multikonfigurationsprojekt das per Ant Script den p2 Director ansteuert um daraus ein Produkt zu erstellen.
Der Director kann von hier heruntergeladen werden:
Buckminster Downloads

 

[Antimon]

Hallo Wildcard, danke für die Infos und sorry für die späte Antwort...

Vorweg noch eins - den Link, den du gepostet hast, kenne ich schon - allerdings werde ich daraus nicht so schlau. Ralf Ebert hat ja ein ähnliches Tutorial, welches sich aber ein ein paar Punkten unterscheidet, allerdings habe ich die Essenz leider noch nicht ganz rausfinden können - ein paar Zusammenhänge fehlen wohl. Den Director habe ich auch, durch deinen Beitrag ist mir das Zusammenspiel wieder etwas klarer geworden - leider fehlt mir aber noch der komplette Durchblick

Vielleicht noch eine übergeordnete Frage: Mein Ziel ist es, Release-Versionen der Anwendungen bereitzustellen, als auch die nightly Builds. Wie wird sowas in der Praxis gehandhabt, was für Empfehlungen gibt es da? Aus dem Bauch heraus würde ich sagen, es gibt je eine Update Site, z.B. updates.xyz.de/release/abc und eine updates.xyz.de/nightly/
Die Release-Site wird von Hand gepflegt, während die Nightly-Build-Site per Hudson gebaut und dann automatisiert (z.B. per FTP) auf den Server hochgeladen wird.
Sehe ich das richtig? Baut man dann eigene Update-Site-Projekte für die Releases oder nimmt man die gleichen her, die auch für die Nightly Builds verwendet werden - nur halt wenn eine gewisse Stabilität erreicht wird?

Und deiner Aussage nach würde ich zu dem Zwei-Schritt-Verfahren tendieren - erst die Update Site bauen und dann daraus per Director die plattformspezifischen Builds.
Die erste Frage wäre aber - wie bekomme ich mein Workspace-Verzeichnis so hin wie ich es brauche?
Im SVN sind die Plugins nach folgendem Schema abgelegt:
applikation/plugins/pluginname/trunk

Im Workspace müsste das Schema aber so aussehen oder?
/plugins/org.xyz.pluginname/

Wie bekomme ich das Layout am sinnvollsten so hin? Einerseits könnte man Hudson veranlassen, die Dateien aus dem SVN entsprechend auszuchecken und Buckminster die Dateien fertig präsentieren - andererseits wäre es wohl sinnvoller, über die rmap-Dateien Buckminster selbst alles Benötigte materialisieren zu lassen - sehe ich das richtig?

Und wenn die Dateien dann mit diesem Job lokal vorhanden sind - wie kann ich in dem plattformspezifischen Buid-Projekt darauf zugreifen? Das hat doch einen eigenen Workspace, wo kann ich diesen ändern? Vermutlich habe ich einfach noch nichts in Hudson gefunden, aber das geht oder?

Sorry - is wieder einiges an Text geworden, ich hoffe es erschlägt nicht beim Lesen - aber es sind leider noch manche Dinge für mich nicht so klar - aber es wird, mit Eurer Hilfe schaff ich das

 

[Wildcard]

Ich finde es sinnvoll den Checkout von Hudson übernehmen zu lassen, da dann SCM triggered Builds funktionieren und Hudson das Changelog wiedergeben kann. Buckminster kann dann einen local resolver verwenden um die von Hudson ausgecheckten Projekte in den Eclipse Workspace zu importieren (phsyikalisch sind die beiden identisch).
Wenn du einen Multikonfigurationsjob verwendest, hat jede Kombination ihren eigenen Workspace (ein eigener Checkout).
Wenn du einen Job hast, der die Update Site baut, und einen Job der mit dem Director ein Product aus der Site baut, dann braucht der 2te Job von Buckminster gar nichts zu wissen und du brauchst auch nichts auszuchecken. Du übergibst einfach die URL der Update Site an den Director.

 

[Antimon]

Danke, das hat mir schon mal sehr weitergeholfen!

Nun möchte ich also in einem Projekt die Update Site bauen... allerdings bekomme ich dauernd folgende Meldung: "[...]/workspace/xxx overlaps the location of another project: 'xxx'
Wobei xxx der Name einer beliebigen Komponente ist, z.B. org.domain.app.xyz

Mir scheint es so, als würde er mit den .project Dateien nicht zurechtkommen, denn jedes Package besteht aus einem separaten Eclipse-Projekt. Vielleicht ist es nicht so gut, dass die .project-Dateien mit ins SVN eingecheckt sind, aber eigentlich dürfte das doch nichts machen? Oder doch?

 

[Wildcard]

Mir scheint es so, als würde er mit den .project Dateien nicht zurechtkommen, denn jedes Package besteht aus einem separaten Eclipse-Projekt.

Jedes Package ist ein Projekt? Warum denn das? ???:L

 

[Antimon]

Sorry, war schon spät... Begriffsverwechslung.

Nein, natürlich nicht jedes Package, sondern jedes Plugin... nur habe ich der Einfachheit halber auch die .project-Files mit eingecheckt, könnte es daran liegen dass er dieses "Overlapping Workspace" bringt? Wobei beim Tutorial Mailapp auch die .project-Files eingebunden sind...

Irgendwie versteh ich das Ganze nicht so...

 

[Wildcard]

Verwendest du einen local resolver? Wer macht denn checkout?

 

[Antimon]

Also ursprünglich habe ich wie von dir empfohlen die Checkouts der Projekte über Hudson selbst gemacht, und zwar deshalb, weil die Verzeichnisstruktur im SVN nach folgendem Schema eingerichtet ist: plugins/ui/trunk/ - im Workspace von Buckminster sollte es ja dann org.xyz.ui/ heissen, also der komplette Package-Name ohne "trunk" - richtig? Also zumindest hat das soweit funktioniert, allerdings kam da auch die Meldung wegen überlappenden Projekten.

Deswegen habe ich dann versucht, das über die rmap zu lösen - in der Hoffnung dass er so intelligent ist, das auszuchecken was er braucht, allerdings hat das auch keinen Erfolg gebracht.

Nachfolgend mal der aktuelle Stand - ich beschreibe es so wie ich es verstanden habe, wenn ich einen Denkfehler habe, bitte korrigieren

In Hudson ist derzeit ein einziger Checkout aus dem SVN eingestellt, und zwar wird von / - Revision 6649: /software/homecontrol/site/trunk nach org.isysbus.homecontrol.site/ ausgecheckt - in dem Verzeichnis befinden sich alle Dateien, die zum Bau der Update Site benötigt werden (sollten).

Danach folgt der Befehl für Buckminster:

importtargetdefinition -A '${WORKSPACE}/org.isysbus.homecontrol.site/rcp.target'
import '${WORKSPACE}/org.isysbus.homecontrol.site/site.cquery'
build
perform -D target.os=* -D target.ws=* -D target.arch=* org.isysbus.homecontrol.site#site.p2

Allerdings kommt schon bei der Site das overlapping-Problem:

[workspace] $ /opt/sun-jdk-1.6.0.29/bin/java "-Dbuckminster.output.root=/home/tomcat/.hudson/jobs/HomeControl Update Site/workspace/buckminster.output" "-Dbuckminster.temp.root=/home/tomcat/.hudson/jobs/HomeControl Update Site/workspace/buckminster.temp" -Xmx256m -jar /home/tomcat/buckminster_3.7/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -application org.eclipse.buckminster.cmdline.headless -data "/home/tomcat/.hudson/jobs/HomeControl Update Site/workspace" --loglevel warning -S "/home/tomcat/.hudson/jobs/HomeControl Update Site/workspace/commands.txt"
ERROR   Invalid project description.
  OK
  ERROR   /home/tomcat/.hudson/jobs/HomeControl Update Site/workspace/org.isysbus.homecontrol.site overlaps the location of another project: 'org.isysbus.homecontrol.site'
[DEBUG] Skipping watched dependency update for build: HomeControl Update Site #14 due to result: FAILURE
Finished: FAILURE

Hier noch der Inhalt der rmap:
[XML]<?xml version="1.0" encoding="UTF-8"?>
<rm:rmap xmlns:bc="http://www.eclipse.org/buckminster/Common-1.0" xmlns:rm="http://www.eclipse.org/buckminster/RMap-1.0">
<rm:locator pattern="^org\.isysbus\.homecontrol(\..+)?" searchPathRef="svn_repo" failOnError="false"/>
<rm:locator searchPathRef="resources"/>
<rm:searchPath name="resources">
<rmrovider componentTypes="osgi.bundle,eclipse.feature" readerType="local">
<rm:uri format="file:///{0}/{1}/">
<bcropertyRef key="workspace.root"/>
<bcropertyRef key="buckminster.component"/>
</rm:uri>
</rmrovider>
<rmrovider componentTypes="osgi.bundle,eclipse.feature" readerType="p2" mutable="false">
<rmroperty key="buckminster.mutable" value="false"/>
<rm:uri format="http://download.eclipse.org/releases/indigo"/>
</rmrovider>
</rm:searchPath>
<rm:searchPath name="svn_repo">
<rmrovider componentTypes="osgi.bundle,eclipse.feature" readerType="svn">
<rm:uri format="http://svn.isysbus.org/software/homecontrol/plugins/{0}/trunk">
<bc:replace>
<bcropertyRef key="buckminster.component"/>
<bc:match pattern="^org\.isysbus\.homecontrol\.(\w+)" replacement="$1"/>
</bc:replace>
</rm:uri>
</rmrovider>
</rm:searchPath>
</rm:rmap>[/XML]

Irgendwas mag der Buckminster nicht - aber eine Lösung hab beim Suchen nach dieser Fehlermeldung keine gefunden :-(

 

[Wildcard]

So wie deine RMAP definiert ist, versucht Buckminster nochmal auszuchecken. Es muss aber alles über den local resolver laufen, wenn Hudson den checkout macht.

 

[Antimon]

Naja was ich gepostet habe ist der aktuelle Stand... davor habe ich eben versucht, alles durch den Hudson auschecken zu lassen, nachdem das nicht funktioniert hat, lasse ich den Hudson nur noch das Site-Projekt auschecken und der Rest läuft über die rmap. Im geposteten Code ist der local resolver noch drin, den habe ich zum Testen auch rausgenommen, gebracht hat es aber nichts :-(

Und beide Varianten (Checkout durch Hudson bzw. Buckminster) führen zum selben Ergebnis... überlappende Projekte... was auch immer das bedeuten soll... :-/

 

[Wildcard]

Bedeutet der Eclipse Workspace enthält Bereits ein Projekt X und du versuchst nochmal ein Project X zu importieren.
Ich kann dir nur dazu raten den Workspace nochmal komplett zu löschen und dann nur noch den local resolver zu verwenden und von Hudson den Checkout machen zu lassen.
Workspace vorher löschen ist wichtig, damit die .metadata gelöscht wird in der sich der Eclipse Workspace merkt welche Projekte vorhanden sind und wo sie liegen.

 

[Antimon]

So jetzt bin ich endlich wieder dazugekommen, da weiterzusuchen. Ich hab zuerst wie von dir empfohlen alles umgestellt - leider mit gleichem Ergebnis. Nach längerem Probieren habe ich alle Projektverzeichnisse wie die Plugin-ID benannt und ebenfalls den Projektnamen so bezeichnet - und siehe da, die Meldung erscheint nicht mehr und der Vorgang läuft durch.

Was mir übrigens aufgefallen ist: Der Fehler trat nicht beim Bauen auf - sondern bei der import-Anweisung.

Vielen Dank auf jeden Fall für die geduldige Hilfe, die mich letztendlich zum Ziel gelotst hat - und mittlerweile kenne ich mich mit Hudson und Buckminster auch etwas besser aus.