Wie erkennt ein PlugIn ein zugeordnetes Projekt?

[Crai]

Hallo,

Ich arbeite an einem PlugIn, das in einem TreeViewer bestimmte Ordnerstrukturen erkennen kann und beispielsweise wie der Package-Explorer in der Java-Perspektive als besonderes Objekt zurückgeben und anzeigen soll.

Gedacht habe ich dabei an eine der ".project" - Datei ähnliche Datei, die die Infos zu diesen besonderen Strukturen enthält(genauso wie der Pfad zum Source-Ordner in der .project -Datei,z.B.).

Jetzt meine Frage:
- Wie liest/parst sich mein PlugIn durch solche Dateien?
(Ist dafür der ContentProvider verantwortlich, oder doch schon eher ein Modell,
das sich darum kümmern muss?)

- Oder um das etwas allgemeiner zu sehen:
Wie findet der Package-Explorer raus, dass er eine Ordnerstruktur als Package behandeln und auch anzeigen soll.
Oder wie kann ein C++ Plugin erkennen, dass es sich um das Projekt um ein C++ - Projekt handelt und die darin
enthaltenen Ordner und Dateien speziell angezeigt werden?
Was läuft dabei ab?
Welche Klassen sind an dem beteiligt?


Für jeden Tipp bin ich froh,

Gruß,
Crai

 

[kabel2]

hi again,

projekte können natures haben. eine nature ist quasi der typ des projektes. die nature erhält die möglichkeit, das projekt zu konfigurieren, wenn es geöffnet wird. es könnte z.b. einen builder installieren.

wenn du ein java-projekt erstellst, dann hat das projekt automatisch die java-nature, ebenso die diversen C/C++ projekte. manchmal lassen sich auch natures an- und wieder abschalten, z.b. die ANTLR nature.

wenn das projekt die java-nature hat, dann weiss "jemand", dass es eine datei ".classpath" im project root geben muss. da stehen diverse pfade drinnen, z.b. auch ordner, die als source ordner gekennzeichnet sind; ordner für die kompilate, ... könnte z.b. sein, dass der "package explorer" beim öffnen sich "irgendwie" alle projekte geben lässt, und dann (faul) die struktur preiszugeben. was weiss ich

der "package explorer" zeigt aber nur java-projekte an; nur die kennt er. wie die erstellung des modells genau funktioniert, weiss ich nicht. es wird allerdings einen parser geben, der die java quellen in das modell konvertiert. ob der content provider für den "package explorer" noch an der baumstruktur änderungen vornimmt, keine ahnung.

einstieg: vielleicht die methode org.eclipse.jdt.core.JavaCore#create(IProject).

ziemlich viele unbekannte

 

[Thomas Darimont]

Hallo!

Siehe auch hier:
http://help.eclipse.org/help31/inde...pse.platform.doc.isv/guide/resAdv_natures.htm

Gruß Tom

 

[Crai]

O je, das hatte ich befürchtet!
Danke euch beiden für eure Hinweise! Jetzt kann ich meinen "Forschungen" eine neue
Richtung geben.
Vor ein paar Tagen noch, hab ich gehofft, dass mein Vorhaben relativ zügig umgesetzt werden kann. Da dachte ich noch daran, einen eigenen TreeViewer zu schreiben, einen eigenen ContentProvider zu erstellen und das Ganze auf diesem Weg anzugehen.
Siehe meinen letzten Thread dazu, wo du kabel2 mich sehr weiter gebracht hast.
Aber da war ich wohl mit meinem Denken auf dem Holzweg...

Ok, dann werd ich mich wohl auf die Natures stürzen.
Eines verstehe ich aber nicht ganz. Wenn eine Nature alle Aufgaben diesbzgl. übernimmt,
wofür ist dann noch ein z.B. einem Viewer zugrunde liegendes Datenmodell wichtig
Wenn ich mir das Java Model anschaue, sehe ich da Objekte vom Typ IProjects, IFolders, IFiles,... die dann von den beiden Providern verarbeitet werden und von Listenern als Hilfe für kontextsensitive Menüs benutzt werden.

Eins habe ich zumindest schon gelernt: Es ist nicht immer leicht bei der PlugIn-Entwicklung den Überblick zu bewahren....

Gruß,
Crai

 

[kabel2]

nein, da hast du wieder etwas falsch verstanden.
die nature hat nix mit deinem treeviewer zu tun (fast nix).
warum denkst du, dass du eine neue nature brauchst?

wenn die bibliothek in einem anderen projekt liegt, dann könntest du doch z.b. per DnD den viewer mit der quelle versorgen. AFAIK kannst du in den ant view eine ant datei per DnD reinziehen und der parst das ganze.

du kannst zb auch eine Action zu dem "package explorer" kontextmenü hinzufügen. der user klickt dann rechts, und sagt "open library view" (der hypothetische anzeigetext der Action).

 

[Crai]

Ich glaube ich hab mich da etwas schlecht ausgedrückt und zudem war ich gestern nicht soweit eingelesen.
Ich werde eine eigene Nature erstellen. Natures erlauben es einem Projekt bestimmte Eigenschaften zu geben. Die Eigenschaften dieses Projekts werden sein:
- es besteht aus verschiedenen Bibliotheken
- in einer Bibliothek sind verschiedene Bausteine enthalten
- ein Baustein wird durch mehrere Datei unterschiedlichen Formats (.cpp, .xml,.bmp) beschrieben.
Dies soll natürlich möglichst schön und einfach für den User abgebildet werden.

Es sollen etwa Wizards geben, mit denen man neue Bibliotheken erstellen, neue Bausteine hinzufügen, natürlich auch Properties einzelner Bibliotheken oder Bausteine
bearbeiten kann.
Sagen wir mal so, Ziel des PlugIns soll es einmal sein, sich so zu Verhalten, wie etwa die Java-Umgebung oder auch die Umgebung des C++ PlugIns, das alles halt nur auf Bibliotheks-und Bausteingrundlagen.

Da mir heute die Zeit gefehlt hat, konnte ich aber noch leider keine Versuche, dies zu realisieren, starten. Es blieb heute nur beim Lesen und sich dann Gedanken machen.

Ich hoffe das kann man so mit Natures realisieren?

noch zu einem:

du kannst zb auch eine Action zu dem "package explorer" kontextmenü hinzufügen. der user klickt dann rechts, und sagt "open library view" (der hypothetische anzeigetext der Action).

Das habe ich mir auch überlegt. Doch woher sollte die Action wissen, dass das wirklich eine gültige Bibliothek ist? Wie kann ich sensitiv auf sowas reagieren, wenn ich vom Java-Model nur Objekte vom Typ IFolder, IFile, etc. bekomme? Ich denke ich muss mir ein eigenes Model schreiben, oder? Aber wie? Da hätte ich halt dann gehofft, dass mir meine Nature dann etwas weiterhelfen kann. So, könnte mein Model doch erfahren, ob die Ressourcen Bibliotheks-Ressourcen sind und dann entsprechen reagieren. Oder?

Gruß,
Crai

 

[kabel2]

am besten, vergiss das konzept der "nature" fürs erste.
baue das modell der bibliotheken und lass es per treeviewer anzeigen. den code kannst du später sicher gebrauchen.

erweitern ist kein problem. eines nach dem anderen ;-)

 

[Crai]

Ja, du könntest gut damit recht haben. Schritt für Schritt wär mir auch lieber.
Was mir ein bißchen Kopfzerbrechen bereitet, ist die Tatsache, dass ich relativ bald die ersten Ergebnisse präsentieren muss. Aber ich glaube des is normal beim ersten Praktikum...
Ein großes Problem was ich halt beim Bau eines eigenen Models sehe, ist die Tatsache, dass ich nicht weiß, wie ich es machen sollte, dass mein PlugIn erkennt, das es eine Bibliothek nun vor sich hat.
Vor ein paar Tagen bin ich dann auf die Idee gekommen, mir mal die .classpath Datei anzuschaun, und da sah ich den Eintrag "src path=..." und dachte mir, so könnte mein Modell darauf hinweisen, was meine Bibliothek ist. Mit dieser Idee im Kopf hab ich dann nachgeforscht, wer für diese Datei mit diesen Einträgen verantwortlich ist und bin dadurch bei der Java-Nature gelandet.
Dann dachte ich mir, das muss die Lösung sein, ich brauch auch eine solche Nature und damit hätte ich dann ne Basis mit dem mein Model arbeiten könnte... Außerdem haben sich auch die Funktionsbeschreibungen einer Nature sehr intressant für mich anghört.

Aber am Anfang nur ein Model zu schreiben, um das zu erreichen was ich brauche, wär mir auch lieber!
Wie heißt es so schön: Man wächst ja mit der Herausforderung! Nur sollte diese am Anfang nicht zu groß sein....

Gruß,
Crai

 

[kabel2]

Ein großes Problem was ich halt beim Bau eines eigenen Models sehe, ist die Tatsache, dass ich nicht weiß, wie ich es machen sollte, dass mein PlugIn erkennt, das es eine Bibliothek nun vor sich hat.

das sind zwei getrennte probleme; das hat nichts mit dem modell an sich zu tun. das modell ist eine beschreibung der bibliothek, mehr nicht. dann gibts noch ne schnittstellenmethode, um aus einer IResource/IFile/was-weiss-ich das modell zu erzeugen. WIE du an dieses IResource/IFile/was-weiss-ich kommst, steht woanders im code.

Vor ein paar Tagen bin ich dann auf die Idee gekommen, mir mal die .classpath Datei anzuschaun, und da sah ich den Eintrag "src path=..." und dachte mir, so könnte mein Modell darauf hinweisen, was meine Bibliothek ist. Mit dieser Idee im Kopf hab ich dann nachgeforscht, wer für diese Datei mit diesen Einträgen verantwortlich ist und bin dadurch bei der Java-Nature gelandet.

ok, jetzt hab ich, glaube ich, verstanden, was du willst. der benutzer soll in den projekteigenschaften die möglichkeit erhalten, zu spezifizieren, welche von den resourcen im projekt die "gesuchten" bibliotheken sind. diese information willst du dann in einer zu .classpath analogen datei speichern.

 

[Crai]

Jetz an dieser Stelle muss ich mal Danke sagen für deine viele Geduld!
Das glaube ich, ist manchmal nicht so leicht....

das sind zwei getrennte probleme; das hat nichts mit dem modell an sich zu tun. das modell ist eine beschreibung der bibliothek, mehr nicht. dann gibts noch ne schnittstellenmethode, um aus einer IResource/IFile/was-weiss-ich das modell zu erzeugen. WIE du an dieses IResource/IFile/was-weiss-ich kommst, steht woanders im code.

Und genau das WIE ich an dieses alles komme ist unter anderem mein Problem...

ok, jetzt hab ich, glaube ich, verstanden, was du willst. der benutzer soll in den projekteigenschaften die möglichkeit erhalten, zu spezifizieren, welche von den resourcen im projekt die "gesuchten" bibliotheken sind. diese information willst du dann in einer zu .classpath analogen datei speichern.

Exakt. Und genau deswegen kam ich auf die fixe Idee mit der Projekt-Nature. Ich hoffe damit mein "WIE ich an alles komme"-Problem irgendwie zu lösen. Genau damit wollte ich erreichen, dass mein PlugIn merkt, dass es eine Bibliothek vor sich hat.