Eigene p2 Repositorys aufbauen/verwalten

[Gonzo17]

Servus,

bin mittlerweile schon ein bisschen am Verzweifeln, weil ich "nur" nach einer Möglichkeit suche, meine eigenen Plug-Ins in einem lokalen Repository zu verwalten. Das scheitert bisher an mehreren Stellen. Aber eins nach dem andern.

Vorhanden ist ein Hudson mit Buckminster Plug-In. Die angelegten Jobs funktionieren problemlos, ziehen sich "meinen" Code aus dem SVN und die Eclipse Plug-Ins, die noch in den Dependencies stehen, direkt von der Update-Site. Funktioniert, ist aber langsam. Sollte schneller gehen. Daher die Idee: ich muss meine eigenen Plug-Ins ja nicht ständig neu aus dem SVN und bauen lassen, eigentlich sollte nur der spezielle Job der Komponente diese bauen, alle anderen Komponenten, die eine Abhängigkeit darauf haben, sollten es sich von einer zentralen Stelle besorgen können. Diese zentrale Stelle sollte eben ein Repository sein, in dem dann mehrere Versionen meiner eigenen Plug-Ins liegen. Jeder Buckminster-Build kann sich dann darauf bedienen.

Zuerst habe ich versucht das mit dem b3 aggregator zu realisieren. Das scheiterte daran, dass dieser alle Abhängigkeiten meiner Plug-Ins (also auch Eclipse Plug-Ins) benötigt, um ein vollständiges Repository zu bauen. Das wäre prinzipiell auch kein Problem, allerdings schien es nicht möglich, eine Eclipse Update Site "einfach so" zu spiegeln. Es kam immer wieder zu Konflikten mit Versionen, da nur eine Version eines Plug-Ins beim b3 aggregator verwendet werden darf.

Mein zweiter Weg führte mich dann zu den http://www.java-forum.org/deployment/113108-ant-p2-tasks.html. Um das abzukürzen: ein Repository zu bauen funktioniert problemlos (ungeachtet der Frage wie man es baut). Ist es mal gebaut, kommt es aber zu Problemen. Mit Eclipse kann ich es ganz normal öffnen und die Features/Plug-Ins auch installieren. Sobald ich aber bei einem Buckminster-Build per RMAP auf dieses Repository zeige, kommt folgender Fehler:

Provider eclipse.import(file:///E:/test/p2): materializing to E:/.hudson/jobs/xslteditor/workspace/plugins/com.example.com mon.exporter/
Provider eclipse.import(file:///E:/test/p2): materializing to E:/.hudson/jobs/xslteditor/workspace/plugins/com.example.com mon.img/
Provider eclipse.import(file:///E:/test/p2): materializing to E:/.hudson/jobs/xslteditor/workspace/plugins/com.example.com mon.xslttransformer/
Provider eclipse.import(file:///E:/test/p2): materializing to E:/.hudson/jobs/xslteditor/workspace/features/com.example.co mmon.feature/
ERROR [0003] : IU com.example.common.feature.feature.group/4.0.30000.00145 has no artifacts
ERROR: IU com.example.common.feature.feature.group/4.0.30000.00145 has no artifacts

Näher beschrieben ist das hier. Es handelt sich übrigens nicht um ein konkretes Problem mit Ant p2 Tasks, das Problem tritt auch dann auf, wenn ich direkt die generierte p2 Update Site benutze, die mir Buckminster nach Aufruf der #site.p2 Action liefert. Buckminster liefert da auch sehr wenig Informationen, weshalb es genau scheitert. Und leider scheint auch niemand zu wissen, was dieser Error Code genau bedeutet.

Und jetzt frag ich mal einfach so in die Runde. Vielleicht kann mir bei diesen Problemen niemand helfen, aber kennt ihr eine Alternative? Ich meine, irgendwie muss man das ja machen. Kann mir nicht vorstellen, dass nicht schonmal irgendwie irgendwo von jemandem umgesetzt wurde. Vielleicht benutze ich auch die falschen Werkzeuge oder die Lösung liegt eigentlich schon vor mir und ich seh sie nicht. :bahnhof:

Wäre um jeden Rat dankbar!

 

[Wildcard]

Was hälst du denn von folgender Alternative:
Du definierst ein Feature in das du alle Eclipse Features und Plugins packst (included, nicht required) die du gerne als deine Target Platform betrachten würdest.
Dieses Feature checkst du ein und machst einen Hudson Job mit Buckminster Buildstep.
Erstell ein Query für dein Feature und ruf dann dein.container.feature#site.p2 auf.
Das Build Ergebnis ist dann dein p2 Repository.

 

[Gonzo17]

Das wäre ja im Prinzip das, was ich momentan mit jeder einzelnen Komponente mache, nur eben in einem Schritt. Das würde aus zwei Gründen nicht funktionieren. Der erste Grund ist schlicht, dass das Problem, dieses Repository zu lesen, wohl weiterhin bestehen würde (wie hier beschrieben). Zweitens möchte ich ja, dass bei jedem Build einer Komponente das Produkt dieses Builds im Repository landet und somit für alle anderen Builds, die diese Komponente brauchen, zur Verfügung steht. Immer alle Komponenten zu bauen, wenn sich nur eine Komponente geändert hat, ist für mich da keine Lösung.

 

[Wildcard]

Ahh, ich hatte dich wohl falsch verstanden.
Dann folgendes:
Ein Build der die Target Platform (externe Abhängigkeiten) baut.
Dann n kleine Builds die sich aus der TP bedienen und deine Plugins bauen (site.p2).
Das Build Ergebnis archivierst du mit der Hudson Funktionalität Artefakte archivieren.
Die Build Ergebnisse kannst du dann per Hudson Permalink (las successful build) in deine RMAP einbauen, oder per b3 Aggregator spiegeln

 

[Gonzo17]

Ein Build der die Target Platform (externe Abhängigkeiten) baut.
Dann n kleine Builds die sich aus der TP bedienen und deine Plugins bauen (site.p2).

Genau, so hatte ich es vor bzw mache es gerade auch.

Das Build Ergebnis archivierst du mit der Hudson Funktionalität Artefakte archivieren.

Das is ne gute Idee, darauf bin ich noch nicht gekommen, vor allem mit dem nachfolgenden Hinweis sehr wertvoll.

Die Build Ergebnisse kannst du dann per Hudson Permalink (las successful build) in deine RMAP einbauen, oder per b3 Aggregator spiegeln

Dass es sowas gibt wusste ich nicht, erspart mir aber eventuell viel Arbeit. Scheint eine gute Alternative zu sein.

Meine letzte Frage wäre da noch folgendes. Momentan läuft es bei mir so, dass meine eigenen Plug-Ins in die Target Platform fallen, wenn Buckminster sie wiederverwendet, weil Buckminster anscheinend Plug-Ins nicht direkt aus einem Repository benutzen kann und diese irgendwo ablegen muss. Da in den Workspace nur Source kommt, müssen die Binarys, die wiederverwendet werden, eben momentan in die Target Platform. Gibts eine Möglichkeit die irgendwo anders hinzulegen, zB in einem lokalen Ordner "C:\Buckminster\TempBins" und diesen danach wieder zu leeren? Und speziell in dem Fall mit den archivierten Artefakten, was tut Buckminster da, muss es die dann auch wieder in die TP werfen? Stört mich noch, dass meine eigenen Plug-Ins da auch sind und nicht nur externe Abhängigkeiten, das wäre mir deutlich lieber.

Edit: Das mit dem permanenten Link hat übrigens super geklappt. Gibts denn für diesen permanenten Link auch irgendwelche properties? Generell, haben Hudson und/oder Buckminster irgendwelche speziellen properties, die man einsetzen kann? Ich kenne nur

buckminster.component

und

buckminster.output.root

(sowie ein paar Sachen zu SVN), aber gibts noch mehr und wenn ja, wo kann man die sehen? In den jeweiligen Dokumentationen habe ich nichts gefunden und bei Hudson auf "Systeminformationen" gehe, dann sehe ich auch nur die wirklich ganz allgemeinen, die mir für den speziellen Build nichts bringen.

 

[Wildcard]

Momentan läuft es bei mir so, dass meine eigenen Plug-Ins in die Target Platform fallen, wenn Buckminster sie wiederverwendet, weil Buckminster anscheinend Plug-Ins nicht direkt aus einem Repository benutzen kann und diese irgendwo ablegen muss. Da in den Workspace nur Source kommt, müssen die Binarys, die wiederverwendet werden, eben momentan in die Target Platform. Gibts eine Möglichkeit die irgendwo anders hinzulegen, zB in einem lokalen Ordner "C:\Buckminster\TempBins" und diesen danach wieder zu leeren? Und speziell in dem Fall mit den archivierten Artefakten, was tut Buckminster da, muss es die dann auch wieder in die TP werfen? Stört mich noch, dass meine eigenen Plug-Ins da auch sind und nicht nur externe Abhängigkeiten, das wäre mir deutlich lieber.

Du kannst in Eclipse ein Target File erstellen und das in Buckminster als Target Platform setzen.
Diese Target Platform kann auch locations im File System enthalten. Alles was über http verfügbar gemacht wird, muss allerdings zwingend lokal gecached werden, da der Compiler natürlich zugreifen muss, da kommst du nicht drum rum.
Du kannst auch beliebige Verzeichnise als Target Platform für Buckminster setzen und dort vermutlich auch mit symlinks und der gleichen rumspielen wenn dir das lieber ist.
Du kannst auch Buckminster verwenden um solche Verzeichnisse mit Leben zu füllen, alternativen gibt es sehr viele.

Edit: Das mit dem permanenten Link hat übrigens super geklappt. Gibts denn für diesen permanenten Link auch irgendwelche properties? Generell, haben Hudson und/oder Buckminster irgendwelche speziellen properties, die man einsetzen kann? Ich kenne nur buckminster.component und buckminster.output.root (sowie ein paar Sachen zu SVN), aber gibts noch mehr und wenn ja, wo kann man die sehen? In den jeweiligen Dokumentationen habe ich nichts gefunden und bei Hudson auf "Systeminformationen" gehe, dann sehe ich auch nur die wirklich ganz allgemeinen, die mir für den speziellen Build nichts bringen.

Die Frage ist sehr generisch. Sowohl Hudson als auch Buckminster sind beliebig durch plugins erweiterbar. Was es nicht schon gibt, kann man einbauen. Aber ohne deine Use-Cases zu kennen kann ich dazu nicht viel sagen.

 

[Gonzo17]

Die Frage ist sehr generisch. Sowohl Hudson als auch Buckminster sind beliebig durch plugins erweiterbar. Was es nicht schon gibt, kann man einbauen. Aber ohne deine Use-Cases zu kennen kann ich dazu nicht viel sagen.

Dann mal eine konkrete Frage diesbezüglich. Gibt es eine Property, die zB den Namen "hudson.home" hat und auf das Hudson-Verzeichnis zeigt? Hab mein Hudson momentan lokal, deswegen sieht der Link in etwa so aus: http://localhost:8080/job/exampleJob/lastStableBuild/
Ist zwar nicht weiter dramatisch, aber wenn zB http://localhost:8080 schon als Property vorhanden wäre, dann hätte ich 1. bei Änderung des Hudson-Verzeichnisses weniger Probleme, 2. werden die Links in der RMAP deutlich übersichtlicher. Eventuell kann ich solche Properties auch selbst setzen, geht das, dass die dann überall in Hudson bekannt sind? Hatte es mit mit "Umgebungsvariablen" in Hudson versucht, aber irgendwie wurde das beim Ausführen des Buckminster Builds nicht erkannt.

Du kannst in Eclipse ein Target File erstellen und das in Buckminster als Target Platform setzen.
Diese Target Platform kann auch locations im File System enthalten. Alles was über http verfügbar gemacht wird, muss allerdings zwingend lokal gecached werden, da der Compiler natürlich zugreifen muss, da kommst du nicht drum rum.
Du kannst auch beliebige Verzeichnise als Target Platform für Buckminster setzen und dort vermutlich auch mit symlinks und der gleichen rumspielen wenn dir das lieber ist.
Du kannst auch Buckminster verwenden um solche Verzeichnisse mit Leben zu füllen, alternativen gibt es sehr viele.

Puh ganz schön viel Info für jemanden, der sich damit noch recht wenig auskennt. Aber scheinbar geht es.
Ein Target File hab ich schon, das benutze ich per

importtargetdefinition

um einmalig eine Target Platform für meine Builds zur Verfügung zu stellen.
Dass alles, was nicht lokal ist, irgendwie lokal sein muss, damit Buckminster den Build ausführen kann, ist auch verständlich. Allerdings ist da eben die Frage ob Buckminster einen Unterschied zwischen lokalen p2 Repositorys und solchen aus dem Internet macht. Da ich ja, wie oben beschrieben, nun meine Plug-ins per #site.p2 Action baue und darauf zugreife, sind sie ja eigentlich schon lokal vorhanden, daher möchte ich sie auch nicht nochmal in der Target Platform. Gibts da konkret ne Möglichkeit das zu tun oder müssen die Plug-Ins trotzdem zwingend in die (oder eine) Target Platform?



Edit:
Hab jetzt schon alles mögliche versucht. Wenn ich in der MSPEC den p2 materializer verwende und einen anderen Ort angebe (soll ja absichtlich nicht in "meine" Target Platform), dann findet Buckminster die Plug-Ins beim Build nicht. Wenn ich den filesystem materializer nutze bekomme ich eine UnsupportedOperationException. target platform ist deprecated und workspace macht ja keinen Sinn. :bahnhof:

Dann hab ich noch versucht im target-File eine directory anzugeben, die erst später befüllt wird, in der Hoffnung, dass eine Target Platform ähnlich wie eine p2 site weiterleiten kann - tut sie aber nicht. Es scheint als wärs so - entweder es ist da oder es ist eben nicht da. Mehrere Target Platforms lassen sich wohl nicht nutzen (wäre irgendwo ja auch sinnlos), aber wie sonst kann ich dann meine Plug-Ins verwenden, ohne sie in der Target Platform haben zu müssen?

 

[Wildcard]

Hudson stellt dir by default diese Properties zur Verfügung:
Building a software project - hudson - Hudson Wiki

Du kannst eigene Properties wahlweise pro Job hinzufügen, oder global per Plugin.

Dass alles, was nicht lokal ist, irgendwie lokal sein muss, damit Buckminster den Build ausführen kann, ist auch verständlich. Allerdings ist da eben die Frage ob Buckminster einen Unterschied zwischen lokalen p2 Repositorys und solchen aus dem Internet macht. Da ich ja, wie oben beschrieben, nun meine Plug-ins per #site.p2 Action baue und darauf zugreife, sind sie ja eigentlich schon lokal vorhanden, daher möchte ich sie auch nicht nochmal in der Target Platform. Gibts da konkret ne Möglichkeit das zu tun oder müssen die Plug-Ins trotzdem zwingend in die (oder eine) Target Platform?

Ja, sie müssen immer in eine Target Platform, das sieht p2 so vor. Allerdings ist eine TP ein virtueller Container der eben auch aus mehrere Filesystem locations bestehen kann.

Hab jetzt schon alles mögliche versucht. Wenn ich in der MSPEC den p2 materializer verwende und einen anderen Ort angebe (soll ja absichtlich nicht in "meine" Target Platform), dann findet Buckminster die Plug-Ins beim Build nicht. Wenn ich den filesystem materializer nutze bekomme ich eine UnsupportedOperationException. target platform ist deprecated und workspace macht ja keinen Sinn.

Es bringt dir nichts Bundles irgendwo in die Landschaft materialisiern zu wollen, irgendwie muss das Zeug doch auch wieder gefunden werden. Dafür ist dann zB eine Target Definition da.

Dann hab ich noch versucht im target-File eine directory anzugeben, die erst später befüllt wird, in der Hoffnung, dass eine Target Platform ähnlich wie eine p2 site weiterleiten kann - tut sie aber nicht. Es scheint als wärs so - entweder es ist da oder es ist eben nicht da. Mehrere Target Platforms lassen sich wohl nicht nutzen (wäre irgendwo ja auch sinnlos), aber wie sonst kann ich dann meine Plug-Ins verwenden, ohne sie in der Target Platform haben zu müssen?

Der Editor erwartet das die Locations gefüllt sind. Allerdings kannst du die Definition ja bei dir mit gefüllten Pfaden anlegen und dann die tatsächlichen Pfade per Texteditor anpassen bevor du eincheckst.

Alternativ dazu könntest du deine Zwischenergebnisse auch in einem lokalen Maven Repository ablegen und von dort wieder abholen. Details dazu hier:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=302929
Maven Repository einfach deshalb, weil es für ein Maven Repository normal ist dort ständig neue Artefakte hinterlegt werden, während p2 Sites eher als Block gebaut werden.

Nächste Alternative:
Ein Composite p2 Repository.
Jeder deiner Jobs baut sein eigenes site.p2 als Ergebnis des Builds.
Dann definierst du ein globales p2 Repository das an die anderen per Hudson permalink weiterleitet.

 

[Gonzo17]

Hudson stellt dir by default diese Properties zur Verfügung:
Building a software project - hudson - Hudson Wiki

Danke! Gibt's bei Buckminster auch so eine Übersicht?

Nächste Alternative:
Ein Composite p2 Repository.
Jeder deiner Jobs baut sein eigenes site.p2 als Ergebnis des Builds.

Das ist bereits der Fall.

Dann definierst du ein globales p2 Repository das an die anderen per Hudson permalink weiterleitet.

Tu ich so ähnlich. Ich leite in der RMAP per Hudson Permalink zu den einzelnen Repositorys weiter. Ob ich jetzt in der RMAP immer auf ein Repository zeige oder direkt auf jedes einzelne sollte hier ja keinen Unterschied machen. Allerdings besteht ja weiterhin das Problem, dass die Plug-Ins, die aus diesen p2 Repos gezogen werden, erstmal doch wieder in der Target Platform landen. Das ist der Grund wieso ich überhaupt diese Probleme habe.

 

[Wildcard]

Aber was ist daran denn so schlimm? Der erste Build dauert etwas länger, für alle weiteren kann Buckminster innerhalb weniger Sekunden feststellen das die Target Platform alles benötigte enthält.
Oder hast du Probleme mit dem Plattenplatz?

EDIT:
Ach so, zu den Buckminster Properties:
Buckminster hat ein sehr flexibles Property Model. Erklärt wird das im Bucky Book.
Buckminster stellt Properties zur Verfügung, du stellst Properties in deinen Querys, RMAPs, MSPECs, Cspec und per System Property zur Verfügung.
Environment Variablen können verwendet werden, Eclipse Variablen können verwendet werden und Properties können auch rekursiv expanded werden: ${key.${property}}

 

[Gonzo17]

Oder hast du Probleme mit dem Plattenplatz?

Nein, das ist kein Problem.

Aber was ist daran denn so schlimm? Der erste Build dauert etwas länger, für alle weiteren kann Buckminster innerhalb weniger Sekunden feststellen das die Target Platform alles benötigte enthält.

Nunja, ehrlich gesagt war ich der Meinung, dass das nicht sauber ist. Denn wenn ich in der Target Platform meine eigenen Plug-Ins habe und irgendwann mal ein Job erstellt wird, bei dem nicht darauf geachtet wird, dass eigene Plug-Ins nicht aus der TP gezogen werden sollen, dann kann es passieren, dass neuere Versionen "übergangen" werden.
Angenommen Komponente B, die von Komponente A abhängt, soll neu gebaut werden. Komponente A hatte seit dem letzte Build Änderungen und wurde neu gebaut, es liegt also eine neue Version im Repository. Wird Komponente B gebaut und schaut in die TP, wird es eine passende Version des Plug-Ins finden, allerdings nicht die neuste, da die ja noch nicht in der TP ist (nur im Repo, das aus der #site.p2 Action des Jobs von A entstand). Im Grunde wird niemand merken, dass es erstmal "falsch" lief und der Build wird auch nicht fehlschlagen.
Nun, man könnte jetzt sagen "Dann muss man eben aufpassen und alles sauber definieren". Klar, dann passiert es nicht, wenn die CQUERY entsprechend angepasst ist. Aber leider habe ich in meinem kurzen Berufsleben/Studium bisher schon gelernt, dass man nicht nur beim Benutzer nichts erwarten sollte. Es kommen irgendwann auch mal Entwickler, die etwas schnell tun, dabei nicht groß drauf achten was sie tun und in so einem Fall könnten sie schnell in diese Falle treten.

Die eigentliche Frage ist jetzt allerdings - ist das, was ich machen will, überhaupt so vorgesehen? Oder ist es quasi normal, dass irgendwann alles in der TP landet? Gibts da dann auch keine Versionsprobleme, sprich wird von einem Plug-In in der TP immer die neuste Version genommen wenn mehrere drin sind?

Edit: Eine "Lösung", die ich mir dachte, um das vorzubeugen, wäre jede Nacht einen automatischen Build anzustoßen, der die TP neu baut und ebenso jede Komponente. Damit geht man zumindest dem Problem aus dem Weg, dass die TP irgendwann total zugemüllt mit verschiedensten Versionen ist. Und man stellt sicher, dass zumindest jede Nacht ein sauberer Build entsteht, da ja hier keine "alten" Plug-Ins aus der TP gezogen werden können.

 

[Wildcard]

Die eigentliche Frage ist jetzt allerdings - ist das, was ich machen will, überhaupt so vorgesehen? Oder ist es quasi normal, dass irgendwann alles in der TP landet? Gibts da dann auch keine Versionsprobleme, sprich wird von einem Plug-In in der TP immer die neuste Version genommen wenn mehrere drin sind?

Binäre Bundles müssen immer in die Target Platform, das sieht Eclipse so vor. Es wird auch automatisch immer die neuste Version verwendet die noch zu deinen Constraints passt.

 

[Gonzo17]

Ok, danke für alle Antworten, hast mir sehr geholfen. So wie ich es jetzt dann umgesetzt habe wirds erstmal funktionieren und das ist die Hauptsache.