Wer Rich Clients auf Basis der Eclipse Rich Client Platform (RCP) entwickelt, wird früher oder später mit zwei Problemen bzw. Anforderungen konfrontiert werden:
Die gute Nachricht ist, beide Anforderungen können umgesetzt werden. Der erste Punkt mit der Target Platform, der zweite Punkt mit dem Delta Pack. Allerdings muss der Entwickler etwas Arbeit dafür investieren.
Die klare Empfehlung ist, das gleich zu Anfang des RCP Projektes (also für jeden Workspace) zu erledigen. Dazu benötigt man das plattformabhängige Eclipse RCP SDK mit ca. 20 MB (am Besten Download des Latest Release), das man in ein leeres Verzeichnis entpackt. Der Pfad sollte keine Leerzeichen enthalten, das spart bei der Automatisierung beispielsweise mit Ant später Arbeit. Im jeweiligen Eclipse Workspace ruft man anschließend die Preferences auf und wechselt auf Plug-in Development - Target Platform. Hier wählt man mit dem Browse Button das eben angelegte Verzeichnis aus und bestätigt alle Dialoge (siehe folgenden Screenshot).
Damit wäre, nach der automatischen Neukompilierung, der erste Punkt von oben eigentlich erledigt. Allerdings ist es sehr wahrscheinlich, dass plötzlich Compilererrors auftreten und die RCP nicht mehr funktioniert. Die Ursache dafür ist logisch, es fehlen einfach noch Plug-ins (schließlich ist das RCP SDK ja auch ein ganzes Stück kleiner als beispielsweise Eclipse Classic). Jetzt gilt es die notwendigen Plug-ins zu identifizieren (z.B. per plugin.xml bzw. MANIFEST.MF oder über die Plug-in Dependencies View) und von Hand(!) aus der normalen Eclipse Installation ins Target Verzeichnis zu kopieren. Keinesfalls sollte man jetzt einfach alle Plug-ins kopieren, damit wäre der Vorteil der Target Platform dahin! Die umständliche Prozedur zwingt Entwickler vielmehr, nochmals über Plug-in Abhängigkeiten nachzudenken und manche Dinge vielleicht anders zu entwickeln (und vor allem keine IDE Abhängigkeiten in eine RCP zu bringen).
Neu hinzugefügte Plug-ins müssen immer in den Preferences (wiederum auf der Seite Target Platform) per Reload Button bekanntgemacht werden. Kommen später weitere Plug-in Abhängigkeiten hinzu ist das Vorgehen identisch. Das wiederholt man so lange bis die RCP wieder voll funktionsfähig ist.
Um jetzt noch plattformunabhängig zu werden benötigt man den Eclipse Delta Pack mit ca. 35 MB (ebenfalls auf der Latest Release Download Seite). Diese zip-Datei extrahiert man in das oben angelegte Verzeichnis für die Target Platform (identische Dateien können überschrieben werden). Damit erhält man z.B. auch unter Windows das für Linux notwendige Fragment org.eclipse.swt.gtk.linux.x86_3.4.0.v3448f.jar. Nach dem obligatorischen Klick auf den Reload Button (Preferences) fällt im RCP Export Wizard die Export for multiple platforms Option auf (siehe den nächsten Screenshot). Im Folgedialog lässt sich jetzt auswählen, für welche Plattformen ein Build erstellt werden soll.
Das Vorgehen mutet sicherlich etwas umständlich an, dafür ist jetzt die Zielplattform von der Entwicklungsumgebung entkoppelt, man kann Builds für mehrere Plattformen erstellen und stellt sicher, dass die RCP-Entwicklung nicht auf IDE-basierten Plug-ins besteht. Auch kann man jetzt die neueste Eclipse IDE zur Entwicklung verwenden und die Builds gegen eine andere Version erstellen.
Um sich das Leben später leichter zu machen lässt sich die Target Platform auf einem Netzlaufwerk erstellen und gleichzeitig von mehreren Entwicklern benutzen. Außerdem sollte man für jede zu entwickelnde RCP ein eigenes (frisches) Target Platform Verzeichnis verwenden.
Hi,
ich habe ein eclipse-plugin geschrieben, welches ich nun gerne auf mehreren plattformen freigeben möchte.
ich habe ein neues plugin-project erstellt, kein rpc, damit andere es einfach als .jar in ihr plugin-verzeichnis legen können (mit view also auch SWT) und kann es nur unter meinem os (win) exportieren. wenn ich als target das rpc-delta-pack angebe, bekomme ich nur fehler geschmissen.
wäre super, wenn du mit einen tipp geben kannst, was ich falsch machen könnte. vielen dank schon einmal.
!SESSION 2009-01-09 20:45:00.895 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Framework arguments: -application org.eclipse.ui.ide.workbench
Command-line arguments: -application org.eclipse.ui.ide.workbench -data D:\develop\java/../runtime-EclipseApplication(1) -dev file:D:/develop/java/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application (1)/dev.properties -os win32 -ws win32 -arch x86
!ENTRY org.eclipse.osgi 4 0 2009-01-09 20:45:01.441
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: Application "org.eclipse.ui.ide.workbench" could not be found in the registry. The applications available are: <NONE>.
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:68)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
!ENTRY org.eclipse.osgi 2 0 2009-01-09 20:45:01.456
!MESSAGE One or more bundles are not resolved because the following root constraints are not resolved:
!SUBENTRY 1 org.eclipse.osgi 2 0 2009-01-09 20:45:01.456
!MESSAGE Bundle update@plugins/org.eclipse.core.filesystem.hpux.PA_RISC_1.0.0.v20060603.jar was not resolved.
!SUBENTRY 2 org.eclipse.core.filesystem.hpux.PA_RISC 2 0 2009-01-09 20:45:01.456
!MESSAGE Missing host org.eclipse.core.filesystem_[1.0.0,2.0.0).
.
Hi Peter,
bei der Plug-in Entwicklung brauchst du keine Target Platform, die ist an sich nur bei der RCP Entwicklung für mehrere Plattformen interessant. Du entwickelst für die Eclipse IDE, also brauchst du *ide* Plug-ins. Die gibts in der RCP nicht, daher läuft dein Plug-in auch nicht (eine normale Plug-in Entwicklung wird nie gegen eine RCP Target Platform stattfinden).
Also in deinem Fall zurück zur Standardeinstellung in den Preferences, normaler Plug-in Export und fertig. Das Plug-in ist ohnehin plattformunabhängig, alle plattformabhängigen Plug-ins sind schon in der Eclipse Installation deiner User vorhanden (du lieferst SWT ja nicht mit aus).
Gruß Dominik
Hi Dominik,
vielen dank für die schnelle antwort. als ich diese variante ausprobiert habe, wurde das plugin nicht auf dem mac erkannt. woran kann das dann liegen?
was muss ich dann unter den preferences einstellen, meine eclipse ide und einen haken an "build target platform based on the target's installed plug-ins"? Dann bindet er mir das spezifische swt ein.
ich dachte mir die ganze zeit, dass mein plugin nicht auf dem mac läuft, weil ich das swt und die launcher nicht eingebunden habe.
grüße
peter
ja, deine Preferences Einstellungen mit der IDE und der aktiven Checkbox sind korrekt.
Du exportierst aber zu viel wenn ich das richtig verstehe. Dein Plug-in (die jar Datei die du erstellst) muss an sich nur deine (kompilierten) Sourcen und Ressourcen enthalten, sprich dein core Plug-in. Abhängigkeiten wie SWT sind unnötig.
SWT beispielsweise ist in jeder Eclipse Installation ohnehin vorhanden. Ich vermute mal, dass du deswegen die Probleme mit der Plattformabhängigkeit hast, SWT ist ja plattformabhängig. Also nur dein Plug-in exportieren, und keinerlei eclipse.org Plug-ins mitausliefern. Dann ist dein Plug-in vollkommen plattformunabhängig und die Dateigröße ein ganzes Stück kleiner. Und du verwendest vorhandene Plug-ins wieder, und genau darum geht es u.a. bei Eclipse.
Die Dependencies in der plugin.xml bleiben erhalten, das sind die Installationsvoraussetzungen, damit dein Plug-in installiert werden kann. Das sollte normalerweise nicht einschränkend wirken, außer du hast dermaßen exotische Plug-ins drin stehen...
nochmals danke für deine zeit.
swt für win ist unter den plugin-dependencies. ohne scheint es nicht zu klappen.
leider funktioniert es nicht. gibt es vielleicht noch etwas anderes zu beachten?
ich exportiere nur mein plugin. das ist echt frustrierend...
wahrscheinlich ist es nur ein kleiner fehler. würde denn die möglichkeit bestehen, dass ich dir meine skype adresse zukommen lasse und du mir für nur 5 minuten behilflich bist (mini step by step). ich wäre dir wirklich sehr dankbar und werde dich nicht länger als diese 5 minuten aufhalten.
Das SWT ist falsch wie mir gerade auffällt. Die Abhängigkeit hast du nur oberflächlich gesehen. Und SWT win32 gibt es auf dem Mac natürlich nicht. Brauchst du auch nicht, werf die SWT Dependency komplett raus und setze org.eclipse.ui und bei Bedarf auch org.eclipse.ui.ide, org.eclipse.jface.text ein. Die sind alle plattformunabhängig. Evtl. reicht dir org.eclipse.ui, wenn du dir davon die Dependencies anschaust wirst du SWT finden, org.eclipse.ui bringt also SWT mit.
Plan B: generiere ein neues Plug-in mit dem Wizard, aktiviere die Checkbox bei "UI Contribution" und wähle als Beispiel "Plug-in with a view" aus. Dann schaust du dir die plugin.xml an und übernimmst die Dependencies in deine plugin.xml. Damit sollte es tun, und SWT kommt direkt nicht darin vor.
Falls du damit immer noch Probleme hast schick mir ne Mail an dominik.schadow (at) trivadis.com