Ich waere sehr dankbar wenn su ihn mir zukommen lassen koenntest…
@SirWayne
Ich durfte leider kein xText benutzen ;D
@Unbekannt
Sag Bescheid falls du ne mail brauchst oder so
Ach du bist wieder so einer, der denkt er kann alles alleine besser machen, als ein kompetentes Team
Wird schon Gründe haben, warum dir soviele Leute OSGi ans Herz legen, aber ich mag die beratungsresistenten am liebsten.
Wenn man OSGi lernt kann es auch in der Firma einsetzen, dein Framework zu lernen, da spätestens in 2 Jahren stirbt ist quasi verschwendete Zeit…
Ist ja wie ein eigenes Maven zu schreiben, dafür gibt es ja Standards um Einlernungszeiten zu reduzieren
Dafür gibt es doch jede Menge Vorträge, was die Vorteile und Nachteile jeder Implementierung ist. Google ist dein Freund oder erwartest du, dass das dir jemand aufzählt?
Aber für den Anfang total egal, weil es ja eine Spezifikation ist und du die Implementierung jederzeit austauschen kannst.
Welche Zielsetzung hast du denn? Wenn man Extension Points will gibt es nur Equinox…
Ja was willst mir damit sagen? Eine sehr gut durchdachte und jetzt? JPA ist auch nur eine Spezifikation? Und jetzt was hast du gegen Standards? Lieber das Rad neu erfinden?
Dein Beispiel passt nicht 1 zu 1 es passt einfach gar nicht? Nur weil ein ActionListener ein Interface ist hat es nichts mit einer Spezifikation zu tun. JPA wäre besser als Beispiel gewesen, aber weiß nicht was du mir sagen wolltest…
50 Zeilen ein Plugin System entwickelt, dass kann ja was sein 
Was kann dein Plugin System denn so tolles? Oder hast du einfach paar Interfaces definiert?
wow … wayne … um mal nur auf eine deiner bemerkungen einzugehen
JPA ist eine implementierung … osgi eine spezifikation
ergo : JPA kann man sich als fertige binaries laden und direkt nutzen … was mit osgi so in dem sinne nicht funktioniert
WHAAAAAAT??? Les lieber nochmal nach…
Kannst mir mal zeigen wo du DIE JPA Implementierung runterlädst 
ach … mein fehler … meinte JPF > Java Plugin Framework
bekommst du hier : http://jpf.sourceforge.net/
btw : „Java Plugin Framework“ ist 1) der titel dieses threads und wurde 2) auch öfter genannt …
wollte ich bei deinem ersten post auf diese frage antworten
- Ich weiß nicht was JPF ist und ich weiß auch nicht was DAS Java Plugin Framework ist.
wie komm ich jetzt auf JPA ? … totale verwirrung
Jo versteh dein Problem immer noch nicht… Wie gesagt das Projekt sieht tot aus, also warum auf ein totes Pferd setzen?
PS: Um OSGi zu nutzen musst du ja nicht mal was runterladen, wenn du mit Eclipse entwickelst, ist schon alles da und du kannst sofort beginnen…
du verstehst es glaube ich irgendwie immer noch nicht oder ?
mag sein das du auf deinem profi-level mitlerweile vergessen hast das auch du mal ein anfäger warst der sicher änlich reagiert hat (bzw hätte) wenn er lediglich irgendwas mal eben schnell modular aufbauen will (was ja mit nem interface und ServiceLoader schnell gemacht ist) und dann gleich so ne große keule geschwungen wird
ich will mich auch gar nicht auf irgend so ne belanglose diskusion zwischen profi nutzt osgi - hobby-anfänger lieber interface und ServiceLoader einlassen
fakt ist : es wurde ne simple frage nach einer simplen antwort gestellt, hier auf osgi hinzuweisen mag sicher richtig sein, aber es als das non-plus-ultra-ohne-geht-es-einfach-nicht hinzustellen, und dann wie gesagt sich nicht mal die 5 minuten zeit nehmen um jemanden dinge zu erklären wie eben “da eclipse selbst auf osgi aufbaut kann man damit direkt loslegen” oder “für anwendungsfall X wäre implementierung Y vielleicht besser” … oder nur mal allgemein pro und kontra der einzelnen implementierngen zu nennen … sorry … das ist für mich keine hilfe sondern einfach nur : “hier haste, komm selbst mit klar”
diese einstellung ist beim stand des TO einfach nur unangebracht
[QUOTE=Unregistered]du verstehst es glaube ich irgendwie immer noch nicht oder ?
mag sein das du auf deinem profi-level mitlerweile vergessen hast das auch du mal ein anfäger warst der sicher änlich reagiert hat (bzw hätte) wenn er lediglich irgendwas mal eben schnell modular aufbauen will (was ja mit nem interface und ServiceLoader schnell gemacht ist) und dann gleich so ne große keule geschwungen wird
[/QUOTE]
Wir haben wohl unterschiedlich Auffassungen von modular und dynmaisch…
[QUOTE=Unregistered;72006]
fakt ist : es wurde ne simple frage nach einer simplen antwort gestellt, hier auf osgi hinzuweisen mag sicher richtig sein, aber es als das non-plus-ultra-ohne-geht-es-einfach-nicht hinzustellen, und dann wie gesagt sich nicht mal die 5 minuten zeit nehmen um jemanden dinge zu erklären wie eben “da eclipse selbst auf osgi aufbaut kann man damit direkt loslegen” oder “für anwendungsfall X wäre implementierung Y vielleicht besser” … oder nur mal allgemein pro und kontra der einzelnen implementierngen zu nennen … sorry … das ist für mich keine hilfe sondern einfach nur : “hier haste, komm selbst mit klar”
diese einstellung ist beim stand des TO einfach nur unangebracht[/QUOTE]
Es gibt soviele einfache und gute Tutorials, man kann ja wohl von einem Entwickler 5 Minuten google erwarten. Außerdem sehe ich vom OT keine weiteren Fragen, weil ihn OSGi nicht interessiert hat.
http://www.vogella.com/articles/OSGi/article.html
Einige Vorteile wurden doch auch genannt:
- OSGi ist ein Standard und wird dir auch im Beruf was bringen, das JPF eben nicht
- Einlernen muss man sich in Beides, ich denke mal in OSGi gibt es bessere Tutorials und man hat mehr davon.
So melde mich mal wieder, hatte gerade viel zu tun…
Hab mir osgi angeguckt, recht interessantes Thema, vorallem deren Spezofikation fand ich recht cool, scheibt mir aber nicht schwer zu sein…
Klar kann man JPF und OSGI nicht vegleichen, aber da muss ich Unbekannt recht geben.
Es hat sich bisher keiner die Muehe gemacht die Implementierungen zu vergleichen und was deren Vor und Nachteile sind.
[QUOTE=groggy]
Es hat sich bisher keiner die Muehe gemacht die Implementierungen zu vergleichen und was deren Vor und Nachteile sind.[/QUOTE]
Wie kommst du den darauf?
Auf jeden Fall ist es am Anfang doch egal welche Implementierung, da diese doch total austauschbar sind…
Naja war alles meine Einschätzung und Erfahrung, der Rest musst du entscheiden…
Ja klar, da es ja eine Spezifikation ist sind sie austauschbar, nur hat zB Equinox eben noch ExtensionPoints ind Extensions, wobei Apache Felix vielleicht schnellet ist oder sowas. Darauf wollte ich eigentlich hinaus…
Extension Points etc. sind proprietaere Erweiterungen von OSGi die mittlerweile ueberfluessig sind.
E4 setzt auch viel mehr auf den OSGi Standard.
[QUOTE=maki]Extension Points etc. sind proprietaere Erweiterungen von OSGi die mittlerweile ueberfluessig sind.
E4 setzt auch viel mehr auf den OSGi Standard.[/QUOTE]
Richtig hab ich oben schon mal erwähnt, dass das mit den Extension Points nicht notwendig ist 
Schon klar, mur war das eben ein Beispiel fuer einen Unterschied und nicht dafurr dass es ein guter und notwendiger waere…
Die Unterschiede sind nicht so groß. Man sollte sich am besten an die Spezifikation halten, dann kann eben einfach tauschen. Und Equinox ist weit verbreitet, weil es ziemlich stabil mit vielen Bundles läuft.
Ahso… Ok danke fuer eure Hilfe 
Achso und nicht außer acht zu lassen, sind eben die Open Source Bundles die man dann einfach geschenkt bekommt und sofort nutzen kann und nicht erst in ein unbekanntes Framework rein frickeln muss…
Was meinst du mit Open Source Bundles?
Er meint, dass es jede Menge fertige Bundles gibt, die man nutzen kann. Es steht einem ja nicht nur die OSGi-Implementierung zur Verfügung, sondern eine große Community mit jede Menge Bundles (größtenteils wohl eher OSS, proprietäre Bundles wird man ja eher weniger in die Finger bekommen, außer für die kommerziellen Implementierungen vielleicht, denn trotz gemeinsamer Spezifikation hat jede Implementierung daneben noch diverse spezielle Eigenarten, wegen denen man sich eventuell durchaus für die Implementierung x entscheidet statt für y). Man kann also noch auf ein Repertoire von Bundles zurückgreifen, ganz egal woher die kommen. Anders sieht da schon aus bei einem privaten kleinen Framework/Lib, das/die die Welt nicht kennt, keine Community besitzt, wahrscheinlich zu nix kompatibel ist, weil es nen eigenen Weg eingeschlagen hat und man deshalb eben alles irgendwie zusammenfrikeln muss, was hoffentlich auch gut geht, aber eben bei Problemen allein gelassen wird. Zudem muss man dann, Plugin-Framework hin oder her, jedes Plugin selbst schreiben, da es einfach keine gibt, die man aus der freien Welt so mitnehmen könnte. Wie denn auch, wenn es keiner kennt und niemand drauf zugreifen kann.