Buckminster UpdateSite

[Geeeee]

Kommando zurück.
Die Annahme, dass ich ja nicht alles brauche ist sinnfrei. Irgendwie muss es ja aus den Sourcen gebaut werden und da brauche ich alle Dependencies.
Thread kann gelöscht werden oder verschoben in den Müll oder irgendwas...

Mal wieder ein Anliegen bzgl. automatisierter Builds (nun von UpdateSites)
Wildcard hat mir vor ein paar Monaten schon einmal schön beim Erstellen von TargetPlatforms geholfen. Nun ist leider das Konzept geändert wurden und ich versuche automatisiert eine UpdateSite zu erstellen.

Szenario:
- Plugin Projekt
- Ein paar Features definieren diese Plugins (bin auch schon über das mehrfache .products-Problem gestolpert)
- Das Projekt hat wiederum Abhängigkeiten zu anderen UpdateSites

Zielsetzung:
- Export der projektspezifischen Plugins / Features in Form einer UpdateSite

Lösungsversuch:
Am Anfang habe ich damit angefangen, alle Features in einzelnen cquerys zu definieren und aufzulösen. Hier ergibt sich schon die erste Unschönheit: Er löst auch die geerbten Abhängigkeiten auf (ist ja im Sinne des Erfinders). Natürlich ziehe ich mir damit unnötig viele Daten mit in den Workspace.
Das hab ich erstmal so akzeptiert und wollte nun nach dem Buckminster Buch / Wiki die Legacy UpdateSite (muss eine werden) bauen und dort "einfach nur" meine Features angeben, die auch später in die UpdateSite sollen.
Nun tritt aber ein für mich unlösbares Problem auf: In (mind.) einem Plugin schafft er es nicht die exported Packages aufzulösen und bricht mit "unauffindbar" Fehlermeldung ab.
Diese Plugin ist natürlich auch schon gar nicht mehr eines von denen, die ich gerne in der UpdateSite hätte, sondern ergibt sich aus einer vererbten Abhängigkeit.

Fragen:
1. Ist es möglich, Buckminster zu sagen, dass die direkte Abhängigkeiten gerne geladen werden dürfen, aber tiefere nicht?
2. Vergessen wir Buckminster und bauen die UpdateSite einfach "oldschool". Wie kann man das automatisieren und irgendwann auch in Hudson lösen?

Ich würde sagen, dass die Antwort für 1 NEIN sein wird und schaue mich deshalb schon um, wie man quasi den "Klick" auf "Build All" im UpdateSite-Kontext per commandline lösen könnte. SVN-Update lassen wir mal außenvor, da dieses ja auch mit Hudson später kein Problem darstellen sollte.

Zusatz / Edit:
Sehe gerade, dass ich auch die Möglichkeit habe, das Ganze basierend auf einem Feature (vorerst) umzusetzen. Hier sollte er (Buckminster) am besten gar nicht die Dependencies auflösen sondern einfach nur seine Plugins holen. Wäre das denn möglich?

 

[Wildcard]

Am Anfang habe ich damit angefangen, alle Features in einzelnen cquerys zu definieren und aufzulösen. Hier ergibt sich schon die erste Unschönheit: Er löst auch die geerbten Abhängigkeiten auf (ist ja im Sinne des Erfinders). Natürlich ziehe ich mir damit unnötig viele Daten mit in den Workspace.

Das kannst du ganz einfach vermeiden indem du die Dependencies in deine Target Platform aufnimmst.
Mit Buckminster 3.6 werden binary dependencies übrigens per Default in die Target Platform gesteckt und nur Source Dependencies landen im Workspace. Allerdings bin ich nicht sicher ob man mit Buckminster 3.6 immer noch legacy update sites bauen kann, die sind ja langsam ein wenig 'betagt'

 

[Geeeee]

Da der Thread irgendwie nicht gelöscht wurde und du mir (wieder einmal) die Idee mit Buckminster nicht aus dem Kopf lässt, werde ich einfach hier mal weiterschreiben.

Also habe nun erstmal wieder bei 0 angefangen und versucht aus einer Target Definition die Targetplatform für die späteren Schritte zugänglich zu machen.
Also einfach ein [c]buckminster importtargetdefinition[/c] losgelassen. Natürlich würde ich hier nix schreiben, wenn es nicht geknallt hätte und ein Missing requirement gemeldet wird.
Schaue ich auf die UpdateSite (ist nur eine) aus der TargetDefinition so stelle ich fest, dass dort 100%ig (Version auch verglichen) das Plugin, welches als "missing" gemeldet wird, vorhanden ist.
Kann ich irgendwie nachvollziehen, was buckminster macht bzw. versucht zu tun?
Im "normalen" Workspace arbeite ich auch mit dieser TargetDefinition und es funktioniert ja auch alles.
In den Logs (debug-level) steht nicht viel außer der windowspasswordprovider, der wohl gar nix damit zu tun haben sollte.

Nachtrag: Bei dem "Plugin" handelt es sich um ein Fragment. Das Hostplugin ist auch vorhanden.

 

[Wildcard]

Hast du auch importtargetdefinition -A gemacht um sie zu importieren und zu aktivieren?
Ist das Fragment Platform oder Architekturspezifisch? Vielleicht liegt da der Hase im Pfeffer. Vielleicht passen die Environment Settings der Target Definition nicht auf das Fragment und daher filtert p2 das Fragment aus.

 

[Geeeee]

Ach Mist, vergessen zu sagen: Ja. Ich Depp hab auch vergessen meinen Post zu verfassen.
Es handelt sich gar nicht um irgend so ein Fragment, sondern um das *.swt.win32.* Fragment für das eclipse.swt plugin.
Dieses ist eben Bestandteil eines Features von der UpdateSite aus der ich meine Targetplatform bilde.
Also einfach gesagt: "Feature XY" -> "org.eclipse.swt" <- (reingepumpt) win32 swt Implementierung/dlls
Buckminster in IDE sagt, alles wunderbar. Gleiche Target Definition in Headless: Missing requirement "Feature XY" requires swt.win32
Ich sehe an sich von der Definition her dort keinen Fehler, da ja das Fragment irgendwo als "Plugin" definiert sein muss, damit es sich überhaupt an das SWT-Plugin packt, oder? Evtl. hab ich auch dort genau den Fehler, aber mir fällt keine Lösung dazu ein.

Also ich spreche noch immer über importtargetdefinitions. Das setzte ich gleich mit "Set as Target Platform" in der IDE.

 

[Wildcard]

Wo läuft der Headless Build? Windows/Linux? 32Bit, oder 64Bit?

 

[Geeeee]

Läuft unter Windows. Ist zwar ein 64bit, aber alles "Javatechnische" ist 32.
Hab aber schon das Problem eingrenzen können. Aus irgendeinem Grund wird die win32-Implementierung einmal als TargetPlatform(I) für den Build eine gemeinsame TargetPlatform(II) genutzt. ABER das Plugin wird dann auch explizit nochmal in einem weiteren Feature genutzt, welches in II verwendet wird.
Alle TargetPlatforms sind / werden als UpdateSites bereitgestellt
Wenn ich nun aus I + Sourcen die Nummer II baue, geht alles gut (vor allem das Setzen der TargetPlatform). Versuche ich aber bei dem weiterführenden Build TP.II als target definition zu setzen, um unsere Anwendung zu bauen, sagt er mir, dass er swt.win32 nicht finden kann. Obwohl es mit in der UpdateSite liegt.

Nachtrag:
Ok, gerade geschafft das erste mal richtig die Features über cqueries zu importieren (gab Probleme mit dem SVN). Dort kommt schon beim Import eines Features, welches als Dependency das swt-Fragment hat ein Fehler. Also während des Imports schon bevor ich II überhaupt bauen kann.

Wenn ich das richtig sehe, dann ist das "problematische" Feature, aus dem dann später TP II gebaut werden soll, nur ein "FilterFeature". Es reicht ausgewählte Plugins / Fragmente aus I einfach weiter. Ist wohl ansich kein Problem. Außer eben das swt-Fragment.

 

[Wildcard]

Binde am einfachsten das RCP Feature ein, das sollte alle SWT Fragmente mitbringen.

 

[Geeeee]

Binde am einfachsten das RCP Feature ein, das sollte alle SWT Fragmente mitbringen.

Herr, lass Hirn vom Himmel regnen. Hatte immer in die "falsche" TargetPlatform geschaut und nun endlich mal festgestellt, dass in meiner Target Definition keine Zielarchitektur angegeben wurde.
Nun bräuchte ich nach den ganzen Frustbieren mal ein "Erfolgsbier", aber will mir hier keiner auf Arbeit spendieren

Zu meiner Verteidigung möchte ich gerne sagen, dass in der IDE einfach die gegenwärtige Architektur verwendet wird.