RCP Plugin mit häufig benutzen third libraries

[lam_tr]

Hallo zusammen,

ich habe bei meinen Projekten (Plugin-Entwicklungen) immer wieder viele third libraries in die Runtime hinzugefügt. Kann ich irgendwie eine allgemeines Plugin, auf dem ich jedes Projekt immer draufzugreifen kann, anstatt immer alle libraries separat in die Plugin.xml einzutragen?

Gruss lam

 

[krazun]

Du kannst aus jeder library ein eigenes Bundle machen. Siehe: How to create Eclipse plugins from jars

Dann musst du bei den Bundles in denen die lib gebraucht wird nurnoch das Bundle bei den dependencies hinzufügen hast somit nur ein einziges mal die externe lib und musst sie bei Bedarf auch nur an einer einzigen Stelle aktualisieren und nicht für jedes Bundle seperat.

mfg,
krazun

 

[lam_tr]

HI krazun,

daran habe ich auch schon gedacht, aber wenn ich so vorgehe, werde ich doch mindestens 30 Plug-Ins in meinen Workspace haben. Kennst du noch andere Wege es zu machen?

Gruss lam

 

[krazun]

HI krazun,

daran habe ich auch schon gedacht, aber wenn ich so vorgehe, werde ich doch mindestens 30 Plug-Ins in meinen Workspace haben. Kennst du noch andere Wege es zu machen?

Gruss lam

Was spricht denn dagegen? RCP Anwendungen bestehen in der Regel meist aus sehr vielen Plugins (z.B. Eclipse besteht ja auch aus hunderten von Plugins). Das ist ja das schöne an OSGI/Equinox das man Anwendung sehr einfach modularisieren kann. Für jede externe lib ein eigenes Bundle bedeutet halt auch Flexibilität.

Du könntest auch alle externen libs in ein einziges Bundle packen. Allerdings fügst du dann jedem Bundle immer alle libs aus dem lib-Bundle hinzu, selbst wenn vielleicht nur eine davon gebraucht wird, eine sehr unschöne Lösung also.

Alternativ kannst du die Libraries auch einfach der Target-Platform hinzufügen. Einfach ein Lib Bundle erstellen, exportieren, der Target-Platform hinzufügen und das Projekt aus dem workspace löschen. Dann hast du auch jede Lib nur einmal in der Target-Platform und nicht in jedem Bundle seperat und könntest sie dann trotzdem einzeln den Bundles hinzufügen, in denen sie benötigt werden.

Oder wenn es dir nur darum geht nicht auf eine riesen Projekt-Liste schauen zu müssen kannst du dir auch einfach in Eclipse Working Sets definieren. z.B eines für die ganzen externen lib Bundles und eines für den Rest.

mfg,
krazun

 

[maki]

"Target Platform" ist das Stichwort, du musst gar keinen externen Bundles in deinem Workspace haben, es reicht wenn sie in der Target Platform vorhanden sind.

Gleich kommt bestimmt auch Wildcard und erklärt dir wie man eine Target Platform mit Buckminster materialisieren kann 🙂

 

[Gonzo17]

Gleich kommt bestimmt auch Wildcard und erklärt dir wie man eine Target Platform mit Buckminster materialisieren kann 🙂

Das kann ich auch 😀

Ist recht einfach:

importtargetdefinition -A path/to/eclipse.target

Die Target Platform liegt dann im Workspace, wobei -A bedeutet, dass diese Target Platform dann auch aktiv von Buckminster ab jetzt verwendet wird. Eine Target Definition lässt sich in Eclipse auch ganz einfach anlegen, einfach mal "Plugin-Development" schauen.

 

[lam_tr]

hi maki und gonzo17, was bringt mir wenn ich es unter Buckminster es mache (=materialisiere)?

 

[Gonzo17]

Buckminster generell dient dazu, um dein Eclipse-Projekt zu materialisieren. Es zieht dir zB automatisch fehlende Abhängigkeiten von Update Sites deiner Wahl. Es löst eben deine Feature/Plugin-Struktur auf und baut dir dann dein Produkt. Und die Target Platform ist sowas wie der Grundstein dafür, darauf wird alles gebaut und dahin kommen auch alles Plugins, die Buckminster zum Bauen deines Produkts verwendet (wenn ich mich recht erinnere).

@krazun
Gibt es denn irgendwelche Unterschiede, wenn man aus Jars Plugins macht? Nunja außer eben, dass man sie wie Plugins behandeln kann und entsprechend schöne Abhängigkeiten aufbauen kann. Aber gibts irgendwelche Nachteile? Haben es nämlich bisher so gelöst, dass wir ein Plugin "externals" haben und dort alle "fremden" Jars sind (kein Stückchen Code). Entweder man bindet dann dieses Plugin eben ein oder nicht - aber wenn, dann hat man halt die volle Ladung.

 

[krazun]

Allerdings ist es nicht zwangweise nötig. Wenn man sich eingearbeitet hat hilft es wahrscheinlich die Produktivität im Build Prozess zu erhöhen, allerdings kannst du auch so Bundles zur Target-Platform hinzufügen.

Entweder über eine Target-Definition-Datei oder über Window->Plugin-Development->Target Platform

mfg,
krazun

 

[Gonzo17]

Außerdem will man ja eigentlich auch verhindern, dass irgendwelche Jars in der eigenen Versionsverwaltung vergammeln. Deswegen wäre sowas wie ein repository, das alle deine Abhängigkeiten beinhaltet und cached, eigentlich ideal. Habe gehört Maven kann sowas. Buckminster scheint dafür nur beschränkt geeignet, wobei ich mich meine zu erinnern, dass damals, als ich damit zu tun hatte, gerade irgendwas in der Entwicklung war, also keine Ahnung, ob sich das vielleicht zum Guten gewendet hat. Auf jeden Fall könnte man damit ganz einfach die Abhängigkeiten dann anziehen, wenn man sie braucht und das ziehen ansich geschieht ja eh dann nur einmal.

 

[krazun]

@krazun
Gibt es denn irgendwelche Unterschiede, wenn man aus Jars Plugins macht? Nunja außer eben, dass man sie wie Plugins behandeln kann und entsprechend schöne Abhängigkeiten aufbauen kann. Aber gibts irgendwelche Nachteile? Haben es nämlich bisher so gelöst, dass wir ein Plugin "externals" haben und dort alle "fremden" Jars sind (kein Stückchen Code). Entweder man bindet dann dieses Plugin eben ein oder nicht - aber wenn, dann hat man halt die volle Ladung.

Wie du schon sagst, wenn man aus externen libs Bundles macht kann man gezielter Abhängigkeiten aufbauen. Ich kann z.B in dem GUI-Bundle das Bundle mit JFreeChart und Eclipse-Nebula hinzufügen, aber alle anderen externen libs nicht. Dafür in dem Domain-Bundle dann das JScience Bundle den dependencies hinzufügen ohne die GUI Bundles als abhändigkeiten aufzunehmen.

Als weiteren Vorteil empfinde ich auch das man die Bundles Versionieren kann. Im Normalfall gibt man dem Bundle dann die gleiche Version wie die Library hat. So kann man über die Bundles und dependencies auch leicht die Versionierung verwalten. Man kann in den Dependencies-Properties eines Bundles ja z.B. auch min und max Versionen für ein Bundle angeben. Das geht aber meines Wissens nach nur wenn man die libs in ein Bundle verpackt. Und dann auch nur wenn jedes Bundle nur eine Lib beinhaltet, da man ja nur eine Versionsangabe für ein Bundle vergeben kann.

mfg,
krazun

 

[Wildcard]

Deswegen wäre sowas wie ein repository, das alle deine Abhängigkeiten beinhaltet und cached, eigentlich ideal. Habe gehört Maven kann sowas. Buckminster scheint dafür nur beschränkt geeignet, wobei ich mich meine zu erinnern, dass damals, als ich damit zu tun hatte, gerade irgendwas in der Entwicklung war, also keine Ahnung, ob sich das vielleicht zum Guten gewendet hat.

Ein Repository ist definitiv das richtige Stichwort. Das Problem ist nur, damit Eclipse PDE etwas damit anfangen kann muss es ein P2 Repository sein. Ein solches Repository kann man sowohl automatisiert mit Buckminster oder Maven Tycho bauen, als auch manuell aus Eclipse heraus.
Maven Repositories wären eigentlich wie geschaffen für die Aufgabe, allerdings kann PDE derzeit noch nicht direkt damit kommunizieren. Ich hatte mal PDE gepached um ein Maven Repository direkt in einer Target Platform Definition verwenden zu können, aber mir fehlt etwas die Zeit um es so Rund zu feilen das man es in den Eclipse Code aufnehmen kann.
Wer also ein Maven Repository dafür einsetzen möchte muss zur Zeit ein paar Umwege gehen.
1. Nexus Professional kann ein Repository mit p2 Metadaten dekorieren
2. Eclipse B3 (irgendwann mal der Buckminster Nachfolger) kann Hybrid p2/Maven Repositories erzeugen
3. Ein eigenes processing das p2 Metadaten für ein Maven Repo berechnet.

Hoffentlich tut sich auf PDE oder m2eclipse Seite bald etwas in dieser Richtung, aber falls nicht, dann werde ich mir notgedrungen Variante 3 gegen Ende des Jahres genauer anschauen müssen und hoffe dann eine entsprechende Funktionalität an Apache Archiva spenden zu können. Dann gäbe es zumindest eine FOSS Alternative zur Nexus Professional p2 Funktionalität.