Diskussion:HowTo JPF: Unterschied zwischen den Versionen

Aus Java Student User Group Austria - Java + JVM in Wien Österreich / Vienna Austria
Wechseln zu: Navigation, Suche
(Fragen zu JSP)
 
Zeile 4: Zeile 4:
 
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.  
 
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. [[Benutzer:Mikegr|Mikegr]] 19:55, 1. Jan. 2009 (CET)
 
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. [[Benutzer:Mikegr|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? [[Benutzer:Christoph.pickl|Christoph.pickl]] 21:38, 4. Jan. 2009 (CET)

Version vom 4. Januar 2009, 20:38 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)