Java Plugin Framework funkt nicht

Ich bin so kurz davor den Bildschirm einzuschlagen -.-
Ich habe mir die Demo runtergeladen, ant aufgerufen und was passiert? Es geht nicht! Ne exception fliegt dass er die Klasse nicht finden kann… Scheint bei der kompilierten Demo aber nicht so zu sein. Habt ihr ne Idee warum und koenntet ihr das auch mal testen? Nicht das was bei mir falsch ist…

@Tomate_Salat
Falls du das liest, welche jars brauch ich und was muss ich machen um das System von Eclipse zu nehmen? Vielleicht brauh ich ja ne alternative …

Puh, kann ich dir so aus dem Kopf nicht sagen, da ich seit Monaten nichts mehr mit Eclipse gemacht habe und es schon gut über ein Jahr her ist, dass ich dessen Framework genutzt habe. Aber afair hatte ich damals für Testwecke ein eclipse RCP-Projekt erstellt und erstmal alles von SWT rausgeschmissen. In der Application(?)-Klasse dann den Lifecycle für Swing angepasst und die Dependencies entsprechend angegeben. Dann konnte ich extension Points dort nutzen. Für Plugins musste ich dann nur noch die Anwendung als Target-Plattform angeben und fertig wars. Das ganze Zeug ist auch eher aus einem Spieltrieb heraus entstanden, vielleicht gehts ohne RCP-Projekt. @SirWayne war da glaube ich immer ein guter Ansprechpartner.

Beschreib mal kurz was du vor hast aus deiner Beschreibung kann ich nicht erkennen was du vor hast.
Welche Demo?

PS: Was ist das Java Plugin Framework :D?

Etwas was ich nie wieder verwenden werde -.- seit ganzen drei Stunden sitz ich hier und es fliegen exceptions hin und her…
Ich brauche ein Plugin Framework das mit extension und extrnsion points arbeitet. Dabei bin ich auf JPF gestossen(naja…). Klar eclipse kennt jeder nur weis ich nicht ob man das pure plugin zeugs extrahieren kann.
Da meinte Tomate_Salat er haette das schonmal gemacht (aber mit RCP welches ich komplett rausnehmen will, da ich nur das pure Plugin Framrwork braeuchte) und du waerst ein guter Ansprechpartner gewesen… Vielleicht kannst du mir ja helfen…

Der TO hat ein Framework für Swing Anwendungen geschrieben und möchte dort Plugins realisieren. Seine Beschreibung nach einer Wunschumsetzung in einem anderen Thread (http://forum.byte-welt.net/threads/10385-ein-Swing-Framework?p=71021&viewfull=1#post71021) hat mich dann an die extension Points von Eclipse erinnert und an eine frühere Testumsetzung (die ich sehr grob vor deiner Antwort beschrieben hatte).

Geb ich mal mein Senf dazu was mir einfällt ;), hab noch nicht ganz verstanden was das Ziel ist.

  1. Ich weiß nicht was JPF ist und ich weiß auch nicht was DAS Java Plugin Framework ist.

  2. Ich kenn OSGi und davon die Eclipse Implementierung Equinox, welche mit Extension und Extension Point arbeitet und das meistens noch im Eclipse 3.x. Seit Eclipse e4 wird mehr mit OSGi-Services, DI und EMF gearbeitet, als mit Extension Points. Deshalb ist eine gute Anlaufstelle um modulare Anwendungen zu bauen OSGi, haben wir grad erst mit Vaadin gemacht. Um OSGi richtig zu verstehen sollte man schon ein wenig Zeit in Anspruch nehmen.
    http://www.vogella.com/articles/OSGi/article.html

  3. Gibt es für Swing und OSGi den Netbeans RCP, von dem man sich eventuell was abschauen.

  4. Kann man mit Eclipse e4 (mit ein wenig Aufwand) die UI austauschen und das Plugin System übernehmen. Tom Schindl nimmt die Eclipse e4 und setzt als UI JavaFX drauf.
    http://www.eclipse.org/efxclipse/index.html

PS: Ich weiß nicht was dein Framework besonderes kann, aber das Eclipse e4 bietet für eine Desktopanwendung so ziemlich alles was man braucht und ich bezweifel, dass man noch mehr benötigt.
Es bietet ein (vererbares und erweiterbares) Model für die UI, Dependeny Injection, EventBus, die UI kann man aussuchen (Swing,SWT,JavaFX), OSGi (modularität)…

EDIT: Extensions und Extension Points würde ich nicht mehr umsetzen, dafür gibts bessere Mechanismen z.B. ein gutes Application Model. Deshalb geht man bei Eclips e4 auch wieder mehr von diesem Konzept weg.

JPF(Java plugin framework) ist irgendso ein Framework das ich mal grfunden habe,nichts besonderes…
Was ich will:
Ein Plugin Frameeork das ich bebutzen kann :smiley:

Ich habe mir jetzt JPF nicht angeschaut, aber nur weil Exceptions fliegen, heißt das ja noch nix. Eventuell machst du einfach nur was falsch :wink: Du hast ja noch gar nicht gesagt, was da alles schief läuft …

Aber abgesehen davon … Das Projekt scheint eigentlich tot zu sein, weswegen es nicht unbedingt überraschend sein muss, dass Exceptions hier und da fliegen, aber es ist eben tot. Die letzten Aktualisierungen sowohl an Homepage als auch am Code (welcher übrigens mit CVS versioniert wird) wurden Mitte 2007 gemacht. Im Forum ist auch tote Hose. Ich glaube da wird nix mehr kommen und ist auch nicht mehr viel zu erwarten, vor allem was die Anküpfung an neuere Technologien angeht.

Wie gesagt, ich habe mir das jetzt nicht angeschaut, mag vielleicht tatsächlich gut und ausgereift sein, aber das Projekt selbst ist eben tot. Würde ich persönlich auch lieber die Finger von lassen :smiley: Da kann man nichts garantieren, Zukunftssicherheit schon gar nicht.

So endlich laeuft es… Man muss resourcen die andere plugins lesen sollen explizit exportieren -.- (und ja, sepbst dem code was mich irgendwie verwirrt hat o.O)
Das doofe ist halt das ich keinr alternative dazu kenne die extensions points unterstuetzt. Da bleibt ja dann nur noc das.
Reich anFeatures ist es schon und ausgereift auch(wenn man es nun beherrscht ;D).

Hast du mein Post oben einfach ignoriert, da stehen jede Menge Alternativen, auch welche die Extension Points anbieten. Und auch warum man EP nicht mehr unbedingt verwendet sollte.

Ne…
Ich hab mal was gegooglet, aber ich weiss immer noch nicht ganz was mit Application Model gemeint ist. Koenntest du mir das vielleicht erklaeren?

Und da es ja anscheinend schon Frameworks fuer Swing gibt muss ich ja nicht mehr weiter dran arbeiten. Wusste ja nicht das man eclipwe nehmen kann. Aber ob das Anfaengerrauglich ist ist ne andere Sache…
Hat jemand neue Projektideen?

Naja, wenn es dir um den Lerneffekt geht koenntest du dir dein eigene Plugin Framework schreiben, vorrausgesetzt du haelst die Anforderungen im Rahmen und willst damit nicht irgendwann Poduktiv gehen…

Hab ich auch scjon gemacht :smiley: halt simpel mit ServiceLoader…
Vielleicht ein paar Background Infos:
Ich habe in dem Framework ein paar actions wie about die einen dialog anzeigen. Den kann man setzne muss man aber nicht. Jetzt moechte ich eben die action auf false setzen damit man sie nicht druecken kann. Nur weis ich eben nicht wie man feststellen soll ob man einen dialog gesetzt hat, denn die action hat keinen zugriff auf den dialog und der dialog auch nicht auf die action. So da vielen mir extension points ein. Da haettr man nur nach isPointAvailable oder so fragen muessen und fertig.
Angenommen man hat ein plugin system wie das von osgi mit den Manifest Attributeb. Wie stelle ich nun fest ob der Dialog gesetzt wurde oder nicht?(hierbei muss ein bestimmtes intetface implementiert werden)?

http://www.vogella.com/articles/EclipseRCP/article.html

Zu neuen Projekten, wenn du dich mit Modularität und Plugins usw. beschäftigen willst.
Gibt es erstmal genügend Themen: E4,EMF,Dependeny Injection, OSGi, wenn du das alles geblickt hast.
Themenvorschläge:
Die UI in Eclipse e4 austauschbar machen, für andere ui’s -->JSF,GWT,VAADIN, QT
Oder das aktuelle Framework erweitern in Swing geht noch nicht alles: siehe
http://www.toedter.com/blog/?p=709

@TO
Ich arbeite seit längerer Zeit an etwas ähnlichem. Wenn man sich mal nur dein gegebenes Beispiel betrachtet ist es eigentlich recht einfach :

  1. Listener : du meldest einen Listener am Controller an der benachrichtigt wird sobald ein passendes Plugin für den About-Dialog angemeldet wird. Dabei wird dem Listener eine Instanz eines Interfaces übergeben welche dann im ActionListener des About-Buttons dazu genutzt wird eine doIt()-Methode zu callen und überlässt den Rest dem Plugin (ggf muss man weitere Objekte mitgeben).
  2. direkte Anfrage : man gibt einen besimmten Namen den das About-Plugin haben muss vor und fragt halt beim Controller ob ein Plugin mit diesem Namen geladen wurde. Finde ich jetzt persönlich nicht so schön da man so direkte Abhängigkeiten zwischen einzelnen Modulen schafft die ich mit meinem System eigentlich vermeiden wollte, trotzdem habe ich entsprechenden Code mit drin.

Das ganze kann man natürlich auch umdrehen :

Man gibt eine feste Struktur vor, z.B. eine Menü-Leiste, und die Plugins melden sich nach dem Laden selbst bei dieser an. Das hat dann zum Ergebnis das nur für die Module auch wirklich Menü-Buttons vorhanden sind welche auch geladen wurden. Würde ich persönlich jetzt als eine Mischform der anderen beiden sehen : man schafft zwar die Abhängigkeit das sich die Module an die API der Oberfläche binden, hat aber zwischen den einzelnen Modulen keine direkte Abhängigkeit sondern kann dies über Listener lösen.

Das ganze in einem eigenen Framework zusammen zu fassen ist nicht wirklich schwer, und wenn man es wirlich nur für sich selbst verwenden will kann man hier und da schon mal ein bisschen lazy-code verwenden.
Willst du aber das Plugin-Framework selbst als API bereitstellen (so wie ich es vorhabe) musst du dir schon ganz genau überlegen welche Möglichkeiten du einem Entwickler gibst, vor allem dann wenn ein anderer Entwickler es nutzen möchte um wieder anderen eine public-API anzubieten ohne das diese sich um die interne Arbeitsweise der eigentlichen Anwendung kümmern müssen. Im Idealfall gibt es dann nur ein Interface welches halt eine doIt()-Methode vorschreibt und dann jegliche Kommunikation darüber abläuft so das A mit B zusammenarbeiten kann, sich aber beide nicht direkt kennen müssen.

Ist dein Framework schon verguegbar?

[QUOTE=Unregistered]
Das ganze in einem eigenen Framework zusammen zu fassen ist nicht wirklich schwer, und wenn man es wirlich nur für sich selbst verwenden will kann man hier und da schon mal ein bisschen lazy-code verwenden.
Willst du aber das Plugin-Framework selbst als API bereitstellen (so wie ich es vorhabe) musst du dir schon ganz genau überlegen welche Möglichkeiten du einem Entwickler gibst, vor allem dann wenn ein anderer Entwickler es nutzen möchte um wieder anderen eine public-API anzubieten ohne das diese sich um die interne Arbeitsweise der eigentlichen Anwendung kümmern müssen. Im Idealfall gibt es dann nur ein Interface welches halt eine doIt()-Methode vorschreibt und dann jegliche Kommunikation darüber abläuft so das A mit B zusammenarbeiten kann, sich aber beide nicht direkt kennen müssen.[/QUOTE]

Und warum sollte jemand sowas benutzen, wenn es schon was fertiges, viel mächtigeres gibt, wo sich mehrere sehr schlaue Köpfe darüber bereits Gedanken gemacht haben, wie man ein Modulares System aussehen soll?

Weil man eine kleine Applikation schreibt die vielleicht modular abet dann doch nicht so gross ist um direkt die ganzen sachen von eclipse zu nutzen?
Ich hab mal fuer die Schule eine IDE geschrieben und hab auch nicht EMF und e4 benutzt, da es auch einfach nicht gelohnt hat

Keiner zwingt dich Sachen von Eclipse zu nutzen es gibt genügend Alternativen, auch für kleine Anwendung. Warum etwas nutzen, was nur an einem Mann hängt und wahrscheinlich in 1-2 Jahren nicht mehr weiterentwickelt wird und nicht etwas was sich noch lange bestand hat.
Es gibt mehrere OSGi-Implementierungen:In der wiki Seite steht doch alles

[QUOTE=groggy;71841]
Ich hab mal fuer die Schule eine IDE geschrieben und hab auch nicht EMF und e4 benutzt, da es auch einfach nicht gelohnt hat[/QUOTE]

Für sowas benutzt man auch xText-
Coole Sachen zu benutzen und zu lernen anstatt immer alles neu zu machen und weg zu schmeißen lohnt sich immmer…

wenn du es „Framework“ nennen möchtest und dich etwas lazy-code nicht stört kann ich dir gerne die aktuelle version zur verfügung stellen
ich habe es mitlerweile erfolgreich in zwei meiner projekte einsetzen können und dabei natürlich hier und da noch etwas nachgebessert
für so kleinigkeiten wie dein beispiel was du gebracht hast kann man es bequem verwenden (vielleicht hier und da die eine oder andere kleine anpassung an deinen code nötig)

weil man z.b. einfach kein bock darauf hat immer wieder die gleiche leier zu hören : „nutz doch OSGi“

erlich … seit ich mich mit diesem thema beschäftige kommt immer nur die „OSGi-Keule“ … aber KEINER hat sich auch mal nur 5 minuten zeit genommen die verschiedenen implementierungen gegeneinander zu erklären und für gewisse (auch genannte) zielsetzungen einen vorschlag zu machen …

… denn OSGi ist auch nur eine spezifikation … PUNKT

es wäre genau so witzlos wenn jemand fragt wie man bei klick auf button X aktion Y ausführt …
klar … man könnte sagen : nutz doch das Interface ActionListener …
damit weis dann derjenige zwar WAS er nutzen soll, hat aber immer noch keine ahnung WIE

gut … vielleicht mag das beispiel nicht ganz 1-zu-1 sein … aber genau wegen diesen reaktionen, genau weil immer alle angeheult kommen mit OSGi … genau DARUM habe ich mich zu entschlossen MEINEN code zu nutzen den ICH für MICH entwickelt habe …

und wie man hier sieht ja wohl scheinbar auch mit der richtigen zielsetzung … nämlich es mal irgendwann als kleine 50-zeilen lib anderen hobby-entwicklern und einsteigern zur verfügung zu stellen