Features und Updates

[dzim]

Ich hangel mich ab und an mal von einem mir suspektem Thema zum nächsten.
Jetzt sind oben genannte Themen dran.

Ich habe heute versuchshalber damit begonnen, Features u.s.w. zu verwenden, allerdings ist mir da noch eingiges irgendwie komisch dran.

Das sie zweifelsohne Sinn machen ist mir völlig klar und der derzeitige Zustand, bei einem wichtigerem Update gleich die ganze Anwendung neu exportieren zu müssen, ist wirklich nicht haltbar - und sinnvoll.

Ich wollte gleich die Projekte zu sinnvollen Gruppen, also Features zusammenfassen, aber irgendwie scheiterts gerade am Verständniss:
Ich wollte ein Core Feature aufmachen, dass nur Core Plugins (Hauptsächlich Backend, ein ganz winziger Teil Frontend) enthält. So weit so gut, aber wenn ich die Plug-Ins auswähle die enthalten sein sollen undanschließend auf Dependencies gehe (ich meine damit, das ich dort Compute verwende), sagt er, die selben Plug-Ins müssten bereits installiert sein um das Feature installieren zu können...

Das Versteh ich nicht.

Ich wollte auch mein GUI-Projekt - das mit der leidigen Hilfe - als Feature verpacken und dort o.g. Core Feature einbinden (Features) und beim Druck auf Compute erscheinen wieder einzelene Plugins, die eigentlich das Core Feature abfrühstücken müsste.

Da ich auch noch keinen Webserver zur Verfügung habe, werden erste updates wohl immer noch als heruntergeladene Update Site stattfinden müssen, aber dazu muss ja erst mal das mit den Features klappen und auch die der Update-Teil in meine Anwendung implementiert werden...

Könnt ihr mir da ein paar Tipps geben?

[edit]
also die Fehler, die ich beim build des Features erhalte, sind auch seltsam

# 28.04.09 16:32:41 CEST
# Eclipse Java Compiler 0.894_R34x, 3.4.2 release, Copyright IBM Corp 2000, 2008. All rights reserved.
----------
1. ERROR in /home/danielz/workspaces/pfs_workspace/SetScrewDriver/src/test/rcp/setscrewdriver/util/filtersettings/model/package-info.java (at line 0)
        //
        ^
The type org.eclipse.swt.widgets.Menu cannot be resolved. It is indirectly referenced from required .class files
----------
1 problem (1 error)

Ok, die package-info.java "Klasse" ist nen komisches JaxB-Ding - aber das sollte eigentlich keine Probleme geben, zumal der normale Export funktioniert...
Und: Ja ich weiß - warum nicht EMF - aber alles zu seiner Zeit, ich bin froh, wenn ich nach und nach was hinbekomme.

 

[Wildcard]

Ich würde dir ja gerne helfen, bin aber aus deiner Beschreibung nicht schlau geworden was wie mit wem zusammenhängt und wo das Problem ist. :bahnhof:

 

[dzim]

Mist.
Ich schaff das - glaube ich - bei jedem neuen Problem, was ich habe euch (sprich: meistens dich) zu verwirren. Oder einfach nur unklar zum Ausdruck zu bringen was mein Problem ist.

Fangen wir so an:
Für Updates benötige ich als allererstes Features. Dazu erstelle ich Feature-Projekte, die meine eigenen Plug-Ins in sich verkapseln. So weit so gut. Bis hier hin ist mir auch alles klar.
Meine Projekte gliedern sich recht klar in Backend und Frontend (sind also nicht so durcheinander, wie mein Ausdruck hier). Mein Gedanke war, das Backend in einem und die GUI + Help Plugin in anderes Feature zu verpacken.
Probleme dabei bereitete mir, das ich nicht verstehe, wie das Feature, das meine Backend-Plugins enthält als Dependencies wieder diese Plugins enthalten müsste. Das hat die Compute-Funktionalität auf der Dependencies-Seite ergeben. Das macht doch aber keinen Sinn!

Ich hatte dann das Backend-Feature erst einmal aufgeben, weil ich mich nicht verrennen wollte, und mich dem Build meines Frontend-Features, das meine GUI und das Help-Plugin enthalten soll, zugewendet. Dabei brach der Build des Features mit oben gezeigter Meldung in den Logs ab... An einem Kommentar...
Ich verstehe nicht, was da das Problem ist.
Die genannte Klasse ist eine JaxB-Klasse, die außer Annotation und Package nix enthält.

Weitere Problem bereitet mir dann das Update als solches:
Eine Update-Site anzulegen ist simpel. Kategorien erstellen, Features rein und fertig.
Der Build schlägt natürlich aus oben genannten Gründen fehl.
Eine Update-Site zu haben ist ja prinzipiell schon schön - ich hab sie, auch wenn die Features nicht gebaut werden konnten, in Eclipse selbst mal geöffnet, das geht schon.
Allerdings ist meine Anwendung eben nicht Eclipse. Daher fehlt mir da der Update Manager oder p2.
Ich hab beim suchen im Netz dazu nur von Lars Vogel nur einen Kommentar gefunden, der besagte, das der Update Manager outdated ist und p2 zu komplex... Super. Aber wie bekomme ich denn nun eine Update-Funktion programatisch in meine Anwendung hinein?
Die ActionFactory, mit der ich mir das Help-Menü reingebaut habe kann das nicht - wahrscheinlich müsste ich es über Standard-IDs in der plugin.xml machen können (was vermutlich auch mit der Hilfe etwas sauberer wäre... aber sei's drum).

Ist das etwas hilfreicher? Ich hoffe!

 

[objcler]

Falls ich dich richtig verstanden habe machst du dir Gedanken über einen effizienten Updatevorgang deiner Anwendung. Richtig?

Wieso hälst du es für nicht sinnvoll bei einem Update einfach die gesamte Anwendung zu laden und dann die alte durch die neue zu ersetzen?

Wie groß ist die Anwendung denn?

Das einfachste ist es einfach bei jedem Update die komplette Anwendung neu zu laden. Damit sparst du dir ggf. viel Arbeit.

Kannst du nochmals begründen, wieso das für dich nicht in Frage kommt?

 

[dzim]

ungefähr trifft es das, ja. Aber ich habe halt weniger Lust immer wieder die (danke einiger externer Binärdateien) 80 MB für das koplette Programm für mehrere Plattformen zu exportieren. Darüber hinaus schreibe ich auch Plug-Ins für die (und andere) Anwendung(en) und finde es eher als schlechten Stil, für ein neues Plug In im Programm es wieder komplett exportieren zu müssen.
Und ich sag mir, lieber einmal richtig viel Arbeit und hinterher nicht mehr, als immer wieder den selben sch...

 

[objcler]

ungefähr trifft es das, ja. Aber ich habe halt weniger Lust immer wieder die (danke einiger externer Binärdateien) 80 MB für das koplette Programm für mehrere Plattformen zu exportieren. Darüber hinaus schreibe ich auch Plug-Ins für die (und andere) Anwendung(en) und finde es eher als schlechten Stil, für ein neues Plug In im Programm es wieder komplett exportieren zu müssen.
Und ich sag mir, lieber einmal richtig viel Arbeit und hinterher nicht mehr, als immer wieder den selben sch...

Was sind das für externe Binärdateien? Machen die das Programm so groß?
Du schreibst, dass für diese Anwendung eine Pluginarchitektur vorhanden ist. Das halte ich in 95% der Fälle für nicht notwendig - aber ich kenne ja deine Anwendung nicht.

Was meinst du mit exportieren?

 

[dzim]

das ist im prinzip eine datenbank-datei, die über eine java-api ausgelesen kann. Was genau, kann ich dir gerade nicht sagen
Und: Ja, die machen das Programm im wesentlichen so groß... Leider.

Exportieren = Ein lauffähiges Programm aus dem Produkt machen.

Noch besteht dieses spezielle Programm nur aus einem Haupteil und einem Help Plug-In, allerdings ist dieses Projekt auch mein Versuchsobjekt für ein wesentlich komplexeres, dessen einzelne Plug-Ins definitiv separiert bleiben sollten und nicht in einem riesigen Programm landen sollten, da ihre Funktionen viel zu unterschiedlich sind - dort macht diese Trennung wirklich Sinn.
Ein Beispiel: Ein Plug-In ist zum manipulieren einer speziellen Datenbank, ein anderes zum bearbeiten von CSV-Dateien, ein weiteres wird für Statistiken noch entwickelt, aber auch Konfiguration von Systemen über WebServices sind geplant... Nix, was in eine einzelne Killer-App sollte - meiner Meinung nach.

 

[Wildcard]

Probleme dabei bereitete mir, das ich nicht verstehe, wie das Feature, das meine Backend-Plugins enthält als Dependencies wieder diese Plugins enthalten müsste. Das hat die Compute-Funktionalität auf der Dependencies-Seite ergeben. Das macht doch aber keinen Sinn!

Zunächst mal: Ein Feature enthält nichts, es managed nur. Im Feature sind nachher also nicht 7 PlugIns, sondern das Feature sagt 'Ich bin verantwortlich für 7 PlugIns'. Des weiteren ist ein Feature nicht verantwortlich für seine Dependencies. Das Feature teilt der Plattform nur mit 'bevor du mich installieren darfst muss dies und jenes vorhanden sein'.
Dein Problem ist also eigentlich gar keines.

Eine Update-Site zu haben ist ja prinzipiell schon schön - ich hab sie, auch wenn die Features nicht gebaut werden konnten, in Eclipse selbst mal geöffnet, das geht schon.
Allerdings ist meine Anwendung eben nicht Eclipse. Daher fehlt mir da der Update Manager oder p2.

Du solltest p2 nehmen.

Ich hab beim suchen im Netz dazu nur von Lars Vogel nur einen Kommentar gefunden, der besagte, das der Update Manager outdated ist und p2 zu komplex... Super.

p2 ist noch etwas problematisch (wird mit 3.5 deutlich besser), sollte deine Anforderungen aber abdecken. Du musst dich eigentlich nur noch entscheiden ob du die p2 UI einbindest, oder nur die p2 Infrastruktur verwenden willst und das Update-Frontend selbst entwickeln willst.

 

[dzim]

Ok, danke für die Erleuchtung, wie Features gedacht sind - ich hatte mir darüber nie wirklich Gedanken gemacht. Offenbar führte das zu einem etwas fehlgeleitetem Verständnis... Wie dem auch sei: Danke für die Erklärung!

Ich habe gestern noch ein wenig mit den Features herumgespielt und habe immerhin die Fehler wegbekommen. Allerdings hat ein Versucht, eine Update-Seite zu bauen noch nicht 100%ig geklappt: Ich habe diese Site zu Versuchszwecken in mein Eclipse eingebunden, allerdings bekomme ich bei jedem Versuch mein Core-GUI-Feature zu installieren, einen Fehler:

Cannot complete the request.  See the details.
Cannot find a solution satisfying the following requirements org.eclipse.swt [3.4.2.v3452b].

Naja, wie auch immer: Ich könnte ja jetzt einfach davon ausgehen, das so etwas wie swt bereits da ist und die dependency entfernen...

Ich würde p2 nutzen wollen und mir nicht die arbeit machen, eine eigene GUI zu implementieren. Die UI einzubinden stellt sicher nicht das Problem dar, doch wie binde ich es in das Menü ein? Oder geschieht das "von selbst", wenn ich die UI einbinde?

[edit]
oder vielleicht reicht es schon zu wissen, welche der vielen p2-plug-ins benötigt werden hierfür.

 

[Wildcard]

Cannot find a solution satisfying the following requirements org.eclipse.swt [3.4.2.v3452b].

Anscheinend referenzierst du eine Version die in deinem Produkt nicht enthalten ist.

oder vielleicht reicht es schon zu wissen, welche der vielen p2-plug-ins benötigt werden hierfür.

Fang doch einfach mal mit allen an und schau was passiert.

 

[dzim]

Ich hab ein bisschen hin und her gesucht und kam auf der Eclipse-Seite zu p2 (Category:Equinox p2 - Eclipsepedia) zu folgender "Anleitung"
Equinox/p2/Adding Self-Update to an RCP Application - Eclipsepedia über einen Link kam ich auch noch zu der Anleitung (nach ein bisschen Suchen) Andrew Niefer: Example Headless build for a RCP product with p2 aber ich muss sagen - die ist ziemlich - komisch.
Zumal ich in meiner gesamten "Geschichte" nichts mit Ant zu tun hatte, steh ich jetzt nen bisschen doof da bei einigen Erklärungen, die ein Basiswissen voraussetzen, das ich nicht habe. Ausserdem schein es doch recht unterschiedliche Herangehensweise zwischen Eclipse 3.4 und 3.5 zu geben.

Immerhin habe ich jetzt den Software Updates... Menüeintrag im Hilfe-Menü

 

[Wildcard]

Du musst ja keinen Headless Build machen wenn du das nicht möchtest. Wenn aber doch, dann würde ich dir eher zu Buckminster raten, das ist wesentlich einfacher als headless PDE Builds.

 

[dzim]

ok, nehmen wir an, ich will den ganz normalen build machen - ohne den (für mich) wundersamen quatsch, dann bleibt dennoch die Frage: Wie geht's denn dann?

Ich vermute mal ich springe direkt zu Punkt 2 im Blog und trage diese Zeilen

generate.p2.metadata = true
p2.metadata.repo=file:${buildDirectory}/repo
p2.artifact.repo=file:${buildDirectory}/repo
p2.flavor=tooling
p2.publish.artifacts=true

genauso wie diese hier

 product=${buildDirectory}/acme.product
configs=win32,win32,x86

Nur wie ich mit dem hier

On the command line we are setting:

* pluginPath: allows us to not copy the com.acme.rcp plugin into the buildDirectory.
* buildDirectory: where all scripts will be generated and the location of our modified acme.product file.
* baseLocation: We use the eclipse install we are running as our base.
* acmePlugin: Define the location of the acme plugin for our custom task.

umgehe, ist mir noch nicht klar.
Den Rest kann ich dann wohl erst mal vergessen.

 

[Wildcard]

Warum benutzt du nicht den export wizard wenn du sowieso nicht automatisiert buildest?

 

[dzim]

*AmKopfKratz* aber muss ich dann nicht p2-spezifische Einstellungen vornehmen?
Es mag ja sein, dass mich das ganze Über p2 etwas zu sehr verwirrt hat, aber wenn ich die Anwendung so (also das product-file) aus Eclipse herraus starte bekomme ich nur die Fehlermeldung, das ich die Installation nicht richtig für Software Updates konfiguriert habe...
Na ich werds mal versuchen, wie es aussieht, wenn ich es normal exportiere...

Danke für die Ratschläge jedenfalls!!!

Sorry, dass ich immer wieder noch herrliche noob-Frage stelle, obwohl ich schon nun eine ganze Weile mir Eclipse RCP herumspiele...

[edit]
Nein: es geht nicht, wenn ich es einfach nur in seinem jetzigen Zustand exportiere (siehe Fehlerdialog weiter oben)

 

[Wildcard]

Du musst noch p2 Metadata erzeugen (bin gerade nicht sicher ob der export wizard das nicht auch irgendwie kann)
Help - Eclipse SDK

 

[dzim]

Das sieht recht selbsterklärend aus. Ich werde es dann einfach mal im Laufe des Tages ausprobieren.
Danke für den Link!

PS: Soweit ich es bisher begriffen habe, geht es mit dem Export-Wizard nicht, aber wenn man Ant nutzen würde, könnte man das wohl mit den selben Parameters in ein entsprechendes Task aufnehmen...

edit:
Interessanterweise bricht der Export der Anwendung mit Fehlern ab, wenn ich Metadaten erstellen lassen will (bei Verwendung des Export Wizards).

 

[dzim]

Ich hab noch mal weiterprobiert:

Problems during export
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:112: The following error occurred while executing this line:
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:143: An error occurred when calling generator.
The following error occurred while executing this line:
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:143: An error occurred when calling generator.
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:112: The following error occurred while executing this line:
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:143: An error occurred when calling generator.
The following error occurred while executing this line:
/home/danielz/workspaces/pfs_workspace/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/assemble.org.eclipse.pde.container.feature.linux.gtk.x86.xml:143: An error occurred when calling generator.

Der Fehler kommt immer wieder und ich musste schnell sein, um das temp-Verzeichniss aus o.g. metadaten-Verzeichnis herauszukopieren.
Ergebnis - besagte Zeilen enthalten

<copy file="/home/danielz/programs/eclipse/plugins/org.eclipse.core.net_1.1.0.I20080604.jar" tofile="${assemblyTempDir}/${pluginArchivePrefix}/org.eclipse.core.net_1.1.0.I20080604.jar"/>

<copy file="/home/danielz/programs/eclipse/plugins/org.eclipse.equinox.p2.director_1.0.4.v20081112-1019.jar" tofile="${assemblyTempDir}/${pluginArchivePrefix}/org.eclipse.equinox.p2.director_1.0.4.v20081112-1019.jar"/>
<copy file="/home/danielz/programs/eclipse/plugins/org.eclipse.equinox.p2.engine_1.0.4.v20080930.jar" tofile="${assemblyTempDir}/${pluginArchivePrefix}/org.eclipse.equinox.p2.engine_1.0.4.v20080930.jar"/>

Die letzen beiden Zeilen sind abwechelnd mal Schuld... Ich werde dann mal die o.g. Variante probieren. Vielleicht geht das ja ohne diese Probleme.

 

[dzim]

Ich muss schon sagen, das mir die Update-Funktionen ein wenig den letzten Nerv rauben:
Der Fehler oben scheint nur durch eine versehentlich falsch eingestellte application-id hervorgerufen worden zu sein.

Interessanterweise ist das Update-Menü im exportiertem Produkt (Software Updates...) überhaupt nicht vorhanden. Wenn ich es zu Testzwecken mittels des Produkts aus Eclipse heraus starte, ist es noch da... Jetzt weiß ich wirklich nicht mehr, wo da ein unterschied sein soll.

Auch interessant ist, dass z.B. org.apache.ant inder der Produktkonfiguration enthalten ist, aber nicht im exportierten Produkt selbst.

WTF!?

edit:
...jetzt hab ich's komplett vergeigt - das Update-Menü ist ganz weg... bei beiden Varianten

edit2:
Nach einigem hin und her ist das Menü wieder vollständig, aber die Generierung der Metataden klappt nicht so recht. Ich habe das Produkt mir Metadaten exportieren lassen, dass ergibt dann nocht ein repository-Verzeichnis, dort, wo das fertige Produkt liegt.

Ich habe folgendes aufgerufen

./eclipse -application org.eclipse.equinox.p2.metadata.generator.EclipseGenerator -config ../SetScrewDriver/linux.gtk.x86/ssd-tool/ -metadataRepository file:/home/danielz/programs/SetScrewDriver/repository/ metadataRepositoryName "PFS Update Site" -artifactRepository file:/home/danielz/programs/SetScrewDriver/repository/ -artifactRepositoryName "PFS Artifacts" -publishArtifacts -publishArtifactRepository -root com.test.rcp.setscrewdriver.application -rootVersion 1.4.5.b -compress -noDefaultIUs -vmargs -Xmx256m

(aus dem Beispiel des Links von Wildcard, s.o., abgeleitet).

Das Programm lief durch, aber leider ohne erkennbaren Erfolg. Die Nachricht, das diese Installation nicht richtig für p2 konfiguriert wurde kommt immer noch... Schade... Hätte ja klappen können.

edit3:
Wenn ich das ganze richtig verstehen würde, könnte ich vermuten, das folgende Zeilen im Log mir sagen könnten, was genau schief geht

!ENTRY org.eclipse.equinox.p2.ui.sdk 2 0 2009-05-04 15:22:38.228
!MESSAGE Could not locate the running profile instance. The eclipse.p2.data.area and eclipse.p2.profile properties may not be set correctly in this application's config.ini file.

 

[Wildcard]

Wie sieht deine config.ini denn aus? Vergleich mal mit deinem Entwicklungs Eclipse.
Viel helfen kann ich leider nicht, da wir noch den Legacy Update Manager verwenden. p2 ist in Version 3.4 einfach noch nicht ausgereift, aber andererseits ist Eclipse 3.5 schon zu nahe um bei einer Neuentwicklung nochmal auf dem alten Update Manager aufzusetzen.
Kurzum: du hast dir einen schlechten Zeitpunkt ausgesucht :bae:

 

[dzim]

ja... das hab ich auch gemerkt...
Ich hab jetzt auch beschlossen, auf 3.5 zu warten und es dann noch einmal zu versuchen, da ich halt auch nicht mehr Energy in den Legacybereich stecken will.

Danke trotzdem für die Tipps - so oder so, hab ich doch einiges lernen können, auch wenn es am Ende nicht so geklappt hat, wie gewünscht. Ich bin zuversichtlich das das noch was wird

Ich berichte dann mal von meinen Erfahrungen mit 3.5, wenn es raus ist!