(Semi-)Automatisch Target Platform erstellen

[Geeeee]

Warnung: Kann Spuren von gefährlichem Halbwissen beinhalten!

Hi,

in den letzten Tagen hab ich mich mit dem erstellen der Target Platform für unser Product beschäftigt.
Grober Ablauf:
UpdateSite erstellen -> In ein "frisches" Eclipse alle Features / Plugins der Update Site installieren -> Die so erhaltenen libs und Ordner (mit jars) als TargetPlatform im Produkt-Workspace verwenden.

Nun dachte ich mir, dass es doch irgendwie einfacher gehen muss, die Target Platform zu bauen: Nachdem nun alle Suchbegriffe ausgeschöpft sind, die mir einfallen und fast alle Ergebnisse von google marked as read sind, seid ihr meine letzte Hoffnung.

Was ich ausprobiert habe:
1.
"deprecated"-Weg über org.eclipse.update.core.standaloneUpdate: D.h. ich schaue auf die Site, was es gibt und installier alles in der Reihenfolge, wie ich es auslese -> Irgendwie scheint die Reihenfolge in der site.xml nicht zu stimmen, da er (verständlicher Weise) manche Dependencies nicht erfüllen kann.
Wäre es denn möglich hier irgendwie alle Feature auf einmal reinzuladen (wie es auch im GUI-UpdateManager möglich ist)?
2.
Update über den p2 director. Kommt nicht sehr weit, da er mir schon beim zweiten Feature sagt, dass es keins ist Hab auch schon mit dem "...feature.group" rumgespielt.

Ich hab mich bis jetzt nur mit dem hinteren Teil beschäftigt, weil ich dachte, dass das erstmal einfacher ist. Das Bauen der Site würde ich natürlich auch automatisieren wollen.
So..nun hoffe ich, dass irgendwer es schonmal geschafft hat, eine Target Platform automatisiert zu erstellen.

Vielen Dank schonmal für's Lesen

Nachtrag: Also wenn ich Variante 1 3x hintereinander ausführe, läuft es, da dann endlich alle Dependencies vorhanden sind. Aber irgendwie ist das Vorgehen sehr bescheiden.

 

[Geeeee]

Zum Teil hab ich es nun gelöst. Die erstelle UpdateSite war schon p2 kompatibel, doch durch das Kopieren auf den Server gingen irgendwie Informationen verloren.
1. Updatesite erstellt (noch nicht automatisch)
2.a Direkte Installation in meine Eclipseinstanz
2.b Kopie auf den Server für die UpdateSite
3. Kopieren der installierten Plugins / Features in ein Target Platform Verzeichnis (Anforderung)
4. Deinstallation der Plugins (da ich sowohl das Product als auch die Target Platform mit der gleichen Instanz bearbeite)
5. Freuen, dass er nicht meckert und läuft.

 

[Wildcard]

Zwei (kombinierbare Wege) um eine Update Site zu bauen:
1. Eine Update Site aus bestehenden Update Sites spiegeln und aggregieren. Hierzu verwendest du den Buckminster bzgw. b3 Aggregator
Buckminster Aggregator User Guide - Eclipsepedia

2. Eine Update Site/p2 Repository aus einem Feature bauen
Dazu am einfachsten Buckminster verwenden, damit kannst du out of the Box eine Update Site aus einem Feature bauen

Was du nun genau mit Target Platform vorhast habe ich noch nicht verstanden. Du kannst zB einfach eine Target Platform definieren in dem du ein .target File anlegst und dann deine Update Site(s) einträgst. Wenn du mir genauer erklären was mit der TP passieren soll kann ich konkreter helfen.

 

[Geeeee]

Hi,

danke für deine Antwort.
Dann versuche ich es mal etwas zu beschreiben:
Die Target Platform wird von unterschiedlichen Projekten verwendet, wir sind aber für die Builds / Änderungen zuständig. Also da sind eben projektübergreifende Komponenten mit drin. Mit / gegen diese Plattform entwickeln wir unser Projekt. Also während der Entwicklung.
Das Deployment erfolgt über "eine Art" Webstarter, der dann unser Projekt holt und die benötigten Komponenten über die UpdateSite nachläd. Da kann man eben auch gut Updates von Grundkomponenten drüber einstreuen, weil nur die einzelnen libs nachgeladen werden müssen.
Also TargetPlatform -> Für uns Entwickler und UpdateSite selbst dann für die Endkunden (ohh mein Gott, jetzt lehne ich mich sehr weit aus dem Fenster, aber bin mir da relativ sicher)
Bis dato haben wir die TargetPlatform eben per Hand erstellt: Eben über Build Site -> Hochladen -> Eclipse Install Software -> Alle Plugins rein in einen best. Ordner --> TargetPlatform für unser Projekt
Nun hab ich alles außer Build Site schon ersetzt und Buckminster hab ich heute schonmal angeschaut, aber war erstmal froh, dass alles danach nun automatisiert läuft. Werde mir das morgen mal in Ruhe nochmal durchschauen.
Endziel (falls ich mir mal noch mehr Zeit abknipsen kann) ist die Integration in Hudson (da komme ich um Buckminster wohl gar nicht mehr rum) und nightly builds sowohl der TargetPlatform als auch dann unseres Produktes.
Aber wie gesagt, das erste Ziel ist erfüllt: Der Buildprozess wurde schonmal etwas vereinfacht durch meinen kleinen Skript und den p2.director.

 

[Wildcard]

Es gibt viele Wege eine Target Platform zu erstellen. Ein Weg ist zB über eine Buckminster MSPEC.
Wie es grundsätzlich funktioniert habe ich hier geschrieben:
Building an RCP application with hudson (Buckminster) - Eclipsepedia

Ein CQuery beschreibt welche Komponente du resolven möchtest, eine MSPEC beschreib was mit der Komponente passieren soll sobald sie aufgelöst wurde.
Du könntest zB ein Feature Project anlegen das alle Features und Plugins included die du gerne in deiner Target Platform hättest. Danach schreibst du eine MSPEC die angibt das alle Komponenten in ein bestimmtes Verzeichnis materialisiert werden sollen (die Target Platform).
Anschließend reicht ein buckminster import your.mspec um deine Target Platform zu bauen.

CQuery:
[XML]<?xml version="1.0" encoding="UTF-8"?>
<cq:componentQuery xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0" resourceMap="your.rmap">
<cq:rootRequest name="org.example.your.feature.that.defines.your.tp" componentType="eclipse.feature"/>
<cq:advisorNode namePattern=".*" useTargetPlatform="false" useWorkspace="false"/>
<cqroperty key="target.arch" value="*"/>
<cqroperty key="target.os" value="*"/>
<cqroperty key="target.ws" value="*"/>
</cq:componentQuery>[/XML]

[XML]<?xml version="1.0" encoding="UTF-8"?>
<mspec xmlns="http://www.eclipse.org/buckminster/MetaData-1.0" name="Target Platform MSPEC"
materializer="p2"
installLocation="${targetPlatformPath}"
url="your.cquery">
<property key="target.arch" value="*" />
<property key="target.os" value="*" />
<property key="target.ws" value="*" />
</mspec>[/XML]

Der letzte Teil der dann noch fehlt ist die Resource Map (RMAP). Die Resource Map dient dazu Buckminster zu sagen welche Komponenten aus welcher QUelle bezogen werden können. Das können zB Update Sites sein, oder URLs, oder Maven Repositories, CVS, SVN, GIT,...

Wenn du diesen Weg gehen möchtest kann ich dir helfen alles einzurichten.
Das schöne an Buckminster, du kannst alles in der IDE konfigurieren und testen und wenn es in der IDE funktioniert, dann funktioniert es auch Headless und in Hudson.

 

[Geeeee]

Wenn du diesen Weg gehen möchtest kann ich dir helfen alles einzurichten.
Das schöne an Buckminster, du kannst alles in der IDE konfigurieren und testen und wenn es in der IDE funktioniert, dann funktioniert es auch Headless und in Hudson.

Vielen Dank für deine Mühe. Denke mal, dass ich dann Anfang kommender Woche das nochmal genau anschaue und dann auf dich zurückkommen würde.

 

[Geeeee]

So. Erste Erfolge gibt es zu vermelden:
Ich kann die TargetPlatform mti Buckminster bauen *ole*!
Dazu aber nun dennoch eine Frage:
Wie kann ich alle mspecs antriggern? Ich würde in den ersten Schritten erstmal auf Hudson verzichten und suche somit einen Weg aus Eclipse bzw. von der command line aus.

 

[Wildcard]

Wie kann ich alle mspecs antriggern?

Warum brauchst du denn mehr als eine?

Ich würde in den ersten Schritten erstmal auf Hudson verzichten und suche somit einen Weg aus Eclipse bzw. von der command line aus.

Aus der IDE File -> Import -> Buckminster -> Materialize from Buckminster MSPEC, CQUERY or BOM
Aus der Commandzeile (mit Headless Buckminster)

buckminster import your.mspec

 

[Geeeee]

Warum brauchst du denn mehr als eine?

Ich dachte für jedes Feature brauche ich eine. Unsere TargetPlatform wird aus ~30 Features erstellt. Ich nehme das alles, wie es mir gegeben wird. Man könnte diese ja wiederum zu einem Feature zusammenfassen, ne? Also ich könnte ja ein TargetPlatform-Feature erstellen und dort die 30 anderen Features reinpacken.
Aber ich hab da irgendwie Panik, dass die UpdateSite dann "falsch" (in Bezug auf unerwartet für den Updater) erstellt wird und unser Produkt nicht mehr startet. (Am Launchen des Produktes kann / will ich nix ändern)

Aus der IDE File -> Import -> Buckminster -> Materialize from Buckminster MSPEC, CQUERY or BOM
Aus der Commandzeile (mit Headless Buckminster)

buckminster import your.mspec

Danke, hab ich gerade installiert und gerade einen kompletten Durchlauf zu erstellen. Erübrigt sich natürlich wenn ich nur ein Feature brauche.

 

[Geeeee]

Nun brauche ich leider nochmal einen kleinen Schubs in die richtige Richtung. Hab nun ein weiteres Feature erstellt, welches alle benötigten Features aggregiert.
1. Beim Buckminster import sehe ich auf einmal einige Features als Grau bzw. Gelb markiert. Ich suche schon verzweifelt irgendeine Beschreibung, was das zu bedeuten hat (da steht unresolved, aber sie sind in der UpdateSite vorhanden aus der ich mich aktuell bediene). Als Resultat werden diese natürlich auch nicht importiert. Die Konsolenausgabe hat ein paar Warnings beim Resolven, aber da ist sind die Features nicht dabei.
[Nachtrag 2: Hoffentlich hat hier noch keiner was ausprobiert. Es klappt. Bitte nicht fragen warum, aber muss wohl irgendwie mit dem Buckminster-Cache zu tun gehabt haben]

2. Der command line-Befehl bietet mir kein import an. Sieht in jeder Doku irgendwie selbstverständlich aus, dass es existiert, aber ich bekomme nur (un)install, listsite und listcommands als möglichen Befehle angezeigt.
[Nachtrag: Hab übrigens wg. proxy Umständlichkeiten das headless-Sitearchiv kopiert und aus diesem installiert.]

Irgendwie wollen Eclipse und ich nicht harmonieren. Das beruht nicht auf Gegenseitigkeit Wenn man mal glaubt, dass man es verstanden hat, gibts gleich wieder ne andere Ecke zum Stoßen. Ach menno.

[Nachtrag 3: Naja, nun läufts erstmal aus Eclipse, fehlt nur noch der headless import. Werde mal in die Eclipse-Installation schauen und evtl. da mal ein Plugin in meine Buckminster-Installation überführen]

 

[Wildcard]

Also ich könnte ja ein TargetPlatform-Feature erstellen und dort die 30 anderen Features reinpacken.

Richtig, du kannst alles in ein Feature packen. Muss auch nicht unbedingt ein Feature sein, es kann auch ein normales Projekt sein das eine buckminster.cspec enthält in die du alle Dependencies enträgst. Dieses Target Platform Projekt ist dann nicht vom Typ eclipse.feature, sondern buckminster.

2. Der command line-Befehl bietet mir kein import an. Sieht in jeder Doku irgendwie selbstverständlich aus, dass es existiert, aber ich bekomme nur (un)install, listsite und listcommands als möglichen Befehle angezeigt.

Headless Buckminster ist ein Eclipse RCP und wie Eclipse selbst modular aufgebaut. Das heißt, wenn du Headless Buckminster installiert hast, enthält es erstmal nur Buckminster Core. Die konkreten Features (PDE, JDT, JUnit, Emma, CVS, Maven, SVN, Git, ...) musst du entweder per

buckminster install

oder mit der Director Application nachinstallieren.
Das sieht dann je nach Feature Konfiguration zB so aus:

cd /path/to/buckminster-headless/
./buckminster install http://download.eclipse.org/tools/buckminster/headless-3.5/
	org.eclipse.buckminster.core.headless.feature
./buckminster install http://download.eclipse.org/tools/buckminster/headless-3.5/
	org.eclipse.buckminster.pde.headless.feature

Wenn du das ganze später auf Hudson übertragen willst übernimmt das Hudson Plugin die installation von Buckminster, das vereinfacht die Sache.
Wenn man Headless Buckminster auf einem Entwickler Rechner zum testen benötigt würde ich ein kleines Shell Script empfehlen um alle benötigten Features zu installieren.

 

[Geeeee]

Super..danke dir. Dachte, dass das "essential" Packet schon alles von buckminster haben sollte, was Standardbefehle angeht. Funktioniert nun wie es soll.
Dann werde ich mich mal in das Builden der UpdateSite und Integration in Hudson stürzen. Kann sich nur um Stunden handeln, bis die nächste Frage kommt.

 

[Geeeee]

Also nun sitzte ich an der UpdateSite und hab mich an den Leitfaden für eine Legacy UpdateSite gehalten (eigentlich tritte der fehler auch bei site.p2 auf, aber so kann ich noch die cspec editieren).
Problem ist, dass wir noch generated features nutzen, um die source features zu erzeugen. Das knallt, wenn ich die UpdateSite baue, indem er meckert, dass
[c]No component named...is known to Buckminster[/c]
Ich kann ihn ja verstehen, aber hab keine Ahnung, wie ich ihn freundlich drauf hinweisen kann, dass es ja noch laut build.properties im feature da sein wird.

 

[Wildcard]

Problem ist, dass wir noch generated features nutzen, um die source features zu erzeugen

Tut mir leid, aber ich verstehe nicht was du meinst? Was für generated Features?

 

[Geeeee]

Also ich hab ein Feature Projekt:
de.beispiel.feature in diesem befinden sich nicht nur ein binary sondern auch ein source folder. Wir stellen einige Sourcen nach Außen (zum Debugging) zur Verfügung. Deshalb wurden in den build.properties dieser features zusätzlich

generate.feature@de.beispiel.feature.source=de.beispiel.feature

Das ist nach der Doku für PDE Builds erstellt wurden. Damit hatte ich nix zu tun und ich muss / will es akzeptieren.
In der feature.xml von de.beispiel.feature ist zusätztlich definiert, dass es das de.beispiel.feature.source Feature braucht.
Wenn ich nun die UpdateSite ganz einfach per PDE Tools erstelle, erhalte ich eben für alle Features, die so beschrieben sind die Sourcen. Aber irgendwie möchte Buckminster nicht verstehen, dass diese eben nicht "physikalisch" vorhanden sind.
Hab schon einige Beispiele über die Definition von source.[bundles/features].jars in den cspecs gelesen und könnte mir vorstellen, dass es darüber möglich sein könnte.
Leider bleiben bis jetzt alle Versuche erfolglos, da die "source features" in den Features als Abhängigkeit definiert sind (und ich auch hierdran nichts ändern kann / soll / darf..*) und Buckminster schon in der "Auflösungsphase" (mir fällt da gerade kein besseres Wort für ein) meckert, dass er eben von einem Feature nicht das "source Feature" finden kann, und abbricht.
Experimentell bin ich erstmal auch für andere Lösungswege offen. Ich denke mal, dass du gute Erfahrungen in der ganzen Eclipse-Welt hast und mir einen oder zwei oder... Tipps geben könntest, wie ich best. Sourcen mit in eine (legacy) UpdateSite bringen kann.
Ich danke dir für deine Mühen. Bin wirklich richtig froh, dass ich dabei nicht im Regen stehen gelassen werde

 

[Wildcard]

Soll es denn definitiv eine Legacy Update Site werden? Was spricht denn gegen eine p2 Site? Bei p2 Sites werden die sourcen automatisch hinzugefügt es sei denn du schaltest dieses Verhalten per property ab.
Ich kannte diese generated source features ehrlich gesagt gar nicht. Ob es dafür direkt eine Buckminster Entsprechung gibt kann ich dir leider nicht sagen, vielleicht steht etwas im Bucky Book.
Eclipse downloads - mirror selection
Falls nein solltest du für dieses spezielle Problem mal in der Buckminster Newsgroup nachfragen:
Eclipse Community Forums: Buckminster

Sollte es kein spezielles Handling für generated source feature geben bleibt noch der Weg über generator.
Du kannst per CSPEC/CSPEX einen generator definieren. Für Buckminster heißt das: Component A generiert Component B on demand. Wenn nun Component A angefragt wird und Component A ein Generator für Component B ist, dann wird auch Component B während der Resolution gefunden.
Allerdings habe ich generator bisher noch nie benötigt, also kann ich nicht mit details dienen.

 

[Geeeee]

Danke für deine Antwort. Das Buch hab ich schon angeschaut, leider auch ohne sinnvolle Erkenntnisse. Eine p2 Site kann es definitiv nicht werden, da wir ein Updatesystem nutzen (und daran kann keiner was ändern), welches gerne eclipse 3.2. kompatible Daten entgegennimmt
Evtl. werde ich einfach einen Zweig mit zwei unterschiedlichen Feature Dependencies bauen, da die Sourcen ja nicht für den Endkunden zur Verfügung stehen müssen, sondern nur für die Entwickler (die alle 3.5 nutzen). Dann kann ich legacy ohne Sourcen bauen und das andere dann als P2.
Davor werde ich mir das Generatoren Thema noch einmal anschauen. Evtl. lässt sich ja dadrüber was rausfinden.
Vielen Dank nochmal. Setze das hier mal auf erledigt. Falls ich was rausfinden sollte, füge ich es später hier an.