Diskussion:HowTo JPF: Unterschied zwischen den Versionen

Aktuelle Version vom 5. Januar 2009, 16:05 Uhr

Warum JPF? Was ist der Vorteil gegenüber dem Extension Mechanismus von Eclipse? Der Extension-Mechanismus ist bereits in das Equinox-Projekt ausgelagert und ein von Eclipse unabhängiges Bundle/Plugin. Ich kann mir nur vostellen, dass man die Funktionalität gerne ohne OSGI hätte. Aber OSGI ist so flexibel, dass läßt sich in jede Anwendung integrieren. Falls OSGI zu kompliziert sein sollte, dann wäre es wohl besser, eine Erweiterung auf Basis von OSGI zu machen, die die Komplexität so gut wie möglich verbirgt, wie zB die Spring Dynamic Modules. Mikegr 19:55, 1. Jan. 2009 (CET)

hm, also du hast deine frage "Was ist der Vorteil gegenüber dem Extension Mechanismus von Eclipse?" selber mit der aussage "Falls OSGI zu kompliziert sein sollte" beantwortet :) ich mag einfache und schoene sachen, die nichts desto trotz genauso maechtig sind. guice ist huebsch, JPA/hibernate ist huebsch, weil ich mich nicht (viel) mit der sache erst beschaeftigen muss um sie einzusetzen, ich will sie einsetzen, punkt.

wie schon die jpf leute sich als ziel machen, steht die einfache verwendung vom framework im vordergrund. mein erster kontakt mit plugin frameworks war knopflerfish, und da war mir dann doch zu viel kontrolle aus der hand genommen. mich stellte sich vor allem immer die frage, wie man solch dynamischen systeme unit testen kann?! mit jpf ist alles irgendwie "beim alten", und dennoch hat man die selben moeglichkeiten wie mit einer osgi implementierung.

"Spring Dynamic Modules"? kannte ich bis jetzt noch nicht, klingt gut, werd ich mir mal anschauen -bzw hast lust nicht auch ein kurzes howto dazu zu schreiben?

PS: mir stellt sich halt auch immer anfangs die frage, wie gut maven damit umgehen kann. zb dependencies woanders als in der pom? nein danke! kein archetyp vorhanden? kein mojo welches das ganze korrekt packetiert? Christoph.pickl 21:38, 4. Jan. 2009 (CET)

Spring Dynamic Modules versuchen den vom Spring Framework bekannten ApplicationContext über eine Menge von Bundle/Plugins herzustellen, sodass die "unerwünschte" Dynamic von OSGI wegfällt. Wenn alle notwendigen Plugins vorhanden und gestartet sind, dann läuft das eigene Plugin wie eine normale Spring-Anwendung. Dh man kann auf Beans bzw. Services zugreifen oder bekommt sie injeziert.

Für Unit-test gibt es auch schon Projekte wie zb Pax Exam. Zum Erzeugen von OSGI-Bundles für Maven gibt es Pax Construct und zum Ausführen von einer Menge von Bundles Pax Runner

Maven kümmert sich nur um die Abhängigkeiten zur Kompilierzeit. Damit ist noch keine Konfiguration zur Laufzeit festgelegt. Deswegen sind die Konfigurationen im MANIFEST.Mf oder plugin.xml auch nicht per se redundant. Das ist ein generelles Problem, dass Entwickler annehmen, dass zur Laufzeit alle Bibliotheken in der genau selben Version vorhanden sind wie zur Kompilierzeit. Wenn dann eine andere Version am Server installiert ist, dann kommt das böse Erwachen.

Natürlich lassen sich anhand der Laufzeitkonfiguration auch die notwendigen Klassen für die Kompilierung berechnen. Daher gibt es von den Maven-Leute auch schon ein Projekt namens Tycho(aka Maven3), wo genau dies angedacht ist. Tycho Overview. Allerdings weiß ich nicht wie weit das vorgeschritten ist. OSGI für Server und für Desktop-Clients ist bis auf das Eclipse-Umfeld ein relativ neues Thema. Sogar die Rich Client Plattform von Eclipse ist noch nicht so alt. Da kommt sicher noch viel mehr. Mikegr 17:05, 5. Jan. 2009 (CET)