RCP The System Bundle was updated

[lumo]

java.lang.IllegalStateException: The System Bundle was updated. The framework must be restarted to finalize the configuration change

bekomme das seit heute (update des eclipse ide auf 3.6 sr2) bei jedem start meiner anwendung.
scheint jetzt keinen einfluss auf die anwendung selbst zu haben, bekomme trotzdem immer die exception, 2x...

 

[Sonecc]

Das ist natürlich doof.
Da ich nun leider keine Glaskugel habe, kann ich dir nur raten, mal nach der Exception zu suchen, wirst einige Ergebnisse bekommen, die dir vielleicht helfen.

 

[maki]

Startest du Eclipse mit dem -clean parameter?
Sollte imho jeder machen, immer.

 

[lumo]

@Sonecc glaskugel hab ich leider auch keine für dich...

ich hab sebst schon gegoogelt und da kam nicht wirklich was raus (einige hatten vermutungen über doppelte einträge in der ini file...)

@maki eclipse starte ich immer mit dem -clean parameter, meine applikation nicht
hinweis: ich bekomme den fehler wenn ich meine app aus eclipse starte (anderst hab ich das jetzt noch nicht versucht...)

 

[maki]

Hast du in diner Targteplattform noch alte Bundles rumliegen (von vor dem Update)?

 

[Sonecc]

Was ich damit andeuten wollte ist, dass du einem zu wenig Infos gibst (wie eigentlich immer)

 

[lumo]

Hast du in diner Targteplattform noch alte Bundles rumliegen (von vor dem Update)?

das wars!
ich hab für den export der app noch equinox-sdk und den delta pack.
beide hatten (nach dem update eh klar) ältere versionen von jars als eclipse selbst... darum waren 2 versionen von singletons da... beim validate der plugins hat er mir das geschrieben... (es wundert mich dass er das beim 'run' nicht gemeldet hat...)

@Sonecc ich geb so viele infos, wie ich glaube dass es wichtig ist, bzw was ich weiss und was ich denke, was sinn macht zu schreiben. wenn ich nen roman von 2 seiten schreib, wirds wohl keiner lesen...

 

[maki]

Schön dass es geklappt hat.
Hast du eigentlich eine eigene target Platform definiert?
Ist imho der Anfang von jedem OSGi/Plugin Projekt, sonst bist du sehr abhängig von der IDE Version (inkl. eventueller Updates) die du nutzt

 

[lumo]

ich hab mir mittlerweile eine target definition gemacht (referenziert aber auf meine installierte ide)

sollte ich meine derzeitige platform target definition ins netzlaufwerk exportieren und dann immer gegen die exportieren? (hab derzeit echt arge kämpfe, dass der export funktioniert - klappt nämlich NIX)

bin beim verzweifeln... wenn das nicht bald klappt, dann muss ich wohl jemanden bezahlen, der mir das löst...

 

[Wildcard]

ich hab mir mittlerweile eine target definition gemacht (referenziert aber auf meine installierte ide)

Das bringt nicht viel. Die Target Definition macht IMO nur Sinn wenn sie keine lokalen Artifakte referenziert. Oft erstellen sich Unternehmen eine eigene Update Site mit dem p2 Mirror Tool, oder b3 Aggregator und referenzieren dann diese Seite. Damit ist man unabhängig von externen Resourcen und der Build verhält sich überall gleich.

sollte ich meine derzeitige platform target definition ins netzlaufwerk exportieren und dann immer gegen die exportieren? (hab derzeit echt arge kämpfe, dass der export funktioniert - klappt nämlich NIX)

Ich würde gar nicht soviel Zeit auf den Export Wizard verschwenden, sondern lieber gleich den Headless Build angehen. Schließlich willst du dein Produkt später doch nicht nur bei dir Bauen können, sondern idealerweise auf zB einem CI Server.
Dafür gibt es zB Maven Tycho oder Eclipse Buckminster. Mit beiden kannst recht einfach p2 Repositories und Eclipse Products bauen. Wenn eure Landschaft recht Maven homogen, passt Tycho gut, bei sehr heterogenen Landschaften eher Buckminster.

 

[lumo]

derzeit versuche ich 'nur' eine lauffähige anwendung zu exportieren
später MUSS das dann so aussehen, dass eine version per CD/download verteilt wird, die dann per update seite aktualisiert werden muss...

was es dazu gibt/braucht, habe ich mir ehrlich gesagt noch gar nicht angesehen...
denn davor muss ich erst noch massig viel programmieren

 

[Wildcard]

später MUSS das dann so aussehen, dass eine version per CD/download verteilt wird, die dann per update seite aktualisiert werden muss...

Ist nicht so wild, wenn dir die Standard p2 Oberfläche genügt musst du dafür keinen eigenen Code schreiben. Das Product muss nur so konfiguriert werden das es Update fähig ist. Übrigens vorsicht mit Features die auch wieder Features enthalten, das lässt sich später nicht mehr richtig updaten

 

[Gast2]

Übrigens vorsicht mit Features die auch wieder Features enthalten, das lässt sich später nicht mehr richtig updaten

Gibts dafür einen Grund.

Das heißt ich sollte in einem Feature kein Feature referenzieren, welches wieder ein Feature beinhaltet?

 

[Wildcard]

Das Problem ist, das Features keine Versionranges, sondern fixe Versionsnummern für included plugins/features enthalten.
Sagen wir du hast ein Feature F1 das Feature F2 und F3 enthält. In F2 befindet sich das Plugin A, in F3 das Plugin B.
Für Plugin B gibt es jetzt ein Bugfix release das du gerne einspielen möchtest.
F3 zeigt auf eine exakte Version von B, also musst du auch F3 austauschen. F1 zeigt allerdings auch auf eine exakte Version von F3, also muss F1 und damit auch das A plugin ausgetauscht werden.
Du kannst also immer nur den Kompletten Abhängigkeitsbaum updaten und nicht einzelne Plugins, oder Features (denn sonst würden Constraints in den bereits installierten Features verletzt).