Nebula Projekte

[Gast2]

Hallo,

wie bindet man nebula projekte richtig mit in die applikation ein???
Ich hab das org.eclipse.nebula.widgets.datechooser, org.eclipse.nebula.widgets.formattedtext runtergeladen.
Dann in meine target platform mit rein gelegt, in mein feature.xml mit rein genommen und dann in mein plugin.xml als required angegeben. so jetzt kann ich die klassen in meiner app vewerden. Doch sobald ich eine Klasse davon verwende bekomm ich eine exception

org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NoClassDefFoundError: org/eclipse/swt/internal/SWTEventListener)
	at org.eclipse.swt.SWT.error(SWT.java:3563)
	at org.eclipse.swt.SWT.error(SWT.java:3481)

Was habe ich falsch gemacht?

 

[dzim]

Hallo?
Der DateChoose selbst hat schenbar noch Alpha-Status - da musst du dich nicht wundern, wenn was noch nicht geht...
Deine Exception sagt doch auch, dass es den Listener nicht findet, ich denke mal, da fehlt noch ne dependency - keine Plug-In-dependency, aber auf jeden Fall zu der Klasse org.eclipse.swt.internal.SWTEventListener

Ich würde vielleicht noch ein bisschen warten, bis das alles tatsächlich in die SWT-API eingegangen ist, wie der CTabFolder u.s.w.
Bau dein Ding einfach so, dass der Aufwand zum austauschen nicht zu hoch wird, wenn es mal released wird - oder jedenfalls den Alpha-Status hinter sich gebracht hat...

 

[Gast2]

ja wenn ich es als thirdparty libary einbinde habe ich keinerlei Probleme....

 

[dzim]

Hast du mal geschaut, in welchem plug-in / feature die klasse sein müsste?
Ich schätze mal, das einfach da was buggy ist - wenn es eine so frühe Version ist, denk ich mal, dass es da auch mal von seiten der Entwickler ungewollt dazu kommen kann, dass eine dependency vergessen wurde aufzulösen.
Da hat wohl die QA geschlampt ;-)

 

[Gast2]

Mhm dann das hab ich noch gar nicht gedacht ... Aber wenn ich es als thirdparty jars einbinde müsste ich doch die gleiche exception kriegen wo sollte der unterschied sein ....

 

[foobar]

Die Nebula-Projekte haben alle noch Alphastatus das heisst aber nichts. Ich verwende auch ein paar Projekte von dort und das läuft wunderbar.

Externe Jars einbinden machste am besten so:

- Jar runter laden
- neues Projekt anhand der Jars erstellen "Create Project from existing jars " oder so. Wichtig: Jars dabei nicht entpacken sondern einbinden.
- Das neue lib-Plugin als Dependency in deinem gui-Plugin angeben.
- Wenn du das Projekt aus Eclipse startest mußt du dann das neue Libplugin auch noch der Runconfig hinzufügen.

 

[Gast2]

Ok... Müsste ich mal versuchen...

Aber warum kann ich die plugins nicht einfach in meine target platform reinhauen und dann also required makieren??
Also mit der org.eclipse.draw2D jar war das kein Problem. Ich hab die meiner target platform dazugenommen und konnte es wie ein normales plugin nutzen...

 

[Wildcard]

Mach einfach in der launch configuration validate dann siehst du schon ob's passt. Ein add required wirkt wunder wenn es probleme gibt.

 

[Gast2]

Also wenn ich validate findet er keine problems... und wenn ich add required mach tut er die nebula projekte dazu machen...

 

[foobar]

Und das "validate plugins prior to launching" nicht vergessen. Dann siehste bei jedem Start sofort ob alles in Ordnung ist.

Klar kannste auch einfach ein Jar in deine Targetplatform legen. Sauberer ist es aber alle Libs als Osgi-Bundles zu importieren und sinnvoll zusammen zu fassen.

 

[Gast2]

ja aber was mich daran stört ist dass man die exported packages angeben muss und in meinem plugin.xml die ja wieder als import packages angeben muss ,oder?

 

[foobar]

Nein, du kannst auch einfach das Bundle als Dependency in deinem Plugin angeben dann mußte keine Packages mehr importieren.

 

[Guest]

ok muss ich morgen mal versuchen... aber als export muss ich sie noch angeben?

 

[Wildcard]

Best practice ist es immer alle Packages zu exportieren und bei interne Klassen .internal. im Package Namen unterzubringen.
Genaueres hier (so wird es Eclipse intern gehandhabt) http://wiki.eclipse.org/index.php/Export-Package

 

[foobar]

Best practice ist es immer alle Packages zu exportieren und bei interne Klassen .internal. im Package Namen unterzubringen.
Genaueres hier (so wird es Eclipse intern gehandhabt) http://wiki.eclipse.org/index.php/Export-Package

Das finde ich sehr merkwürdig. Ich will nicht, daß jemand auf meine internen packages zugreift. Wofür sollte das gut sein?

 

[Wildcard]

nun... es hängt davon ab welches Ziel deine PlugIns verfolgen. Bei Eclipse steht größt mögliche Flexibilität im Schwerpunkt und es hat sich schon öfter gezeigt das die API nicht immer ausreichend ist. Dadurch das aber alles veröffentlich wird kannst du mit internal Dingen Arbeiten solange du dir im Klaren darüber bist das es unsupported ist und sich inkompatibel Ändern wird (Eclipse zeigt dir dort auch Warnings).
Wenn das sich mit der Philosophie deines Projekts/Unternehmens beißt, steht es dir frei Packages selektiv zu exportieren.
Bei Eclipse bin ich jedenfalls sehr froh das ich im Notfall auf alles zugreifen kann wenn ich bereit bin mit den Konsequenzen zu leben.

Zumindest OpenSource PlugIns sollten sich meiner Meinung an diese Vorgabe halten

 

[foobar]

Jetzt verstehe ich auch warum man manchmal diese Warnings sieht *gg*