eclipse plug-in Entwicklung: Kommt man da rein?

[flaite]

Tja. Und irgendwann verlässt man die Grundschule und schaut sich in den eclipse-plugin Foren um.
Es gibt ein Webinterface sowie eine nach Themenbereichen detailliert untergliederte Suche.
Ohne die hätte ich es nicht geschafft:

http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg01000.html

So macht man programmatisch aus einen "normalen" Ordner einen Source-Folder, Bestandteil des Classpath des Projekts.
Als Beispiel dafür, dass ich manche Teile für historisch gewachsen halte. Geht aber. Oder besser: Geht nur, wenn man weiss, wo man nachschauen könnte und selbst dann braucht es ein wenig für die Suche.

Code

		// Add a folder to the classpath. 
//		IJavaProject jProject = project.getProject();
		//1. create the folder (new File()...)
		//2. Obtain a reference to your project (as IProject)
		//3. Obtain a reference to your java project (as IJavaProject)
		//4. Fetch e.g. the raw classpath with getRawClasspath() (on IJavaProject)
		//5. Add your new entry (set the type to IClasspathEntry.CPE_SOURCE) to the
		//previously fetched classpath array.
		//6. Set the new raw classpath on your IJavaProject.
		//folder.getR 
		
		
		IJavaProject jProject = JavaCore.create(project);
		IFolder folder = project.getFolder("/src1");
		IPath newPathEntry = folder.getFullPath();
		IClasspathEntry[] cpEntries = jProject.getRawClasspath();
		/*
		for (IClasspathEntry cpEntry : cpEntries) {
			System.out.println("cpEntry=" + cpEntry);
		}
		*/
		IClasspathEntry pSourceEntryNew = JavaCore.newSourceEntry(newPathEntry);
		
		List <IClasspathEntry> pEntriesList = new ArrayList(Arrays.asList(cpEntries));
		pEntriesList.add(pSourceEntryNew);
		IClasspathEntry[] cpEntriesNew = new IClasspathEntry[cpEntries.length + 1];
		
		pEntriesList.toArray(cpEntriesNew);
		jProject.setRawClasspath(cpEntriesNew, null);

      

[flaite]

Tja. Und irgendwann verlässt man die Grundschule

Tja_2. Und am Folgetag fällt einem auf, dass man wieder in den Kindergarten zurücksollte.
Einen Array um 1 Mitglied zu erweitern geht natürlich mit Systems.arraycopy und nicht mit der Unendlichen Geschichte da oben. 

Code

		IJavaProject jProject = JavaCore.create(project);

		IPath newPathEntry = folder.getFullPath();
		IClasspathEntry[] cpEntries = jProject.getRawClasspath();
		/*
		 * for (IClasspathEntry cpEntry : cpEntries) {
		 * System.out.println("cpEntry=" + cpEntry); }
		 */
		IClasspathEntry pSourceEntryNew = JavaCore.newSourceEntry(newPathEntry);

		// if a sourcefolder with the same path does allready exist, return
		for (IClasspathEntry cpEntry : cpEntries) {
			if (cpEntry.getPath().equals(pSourceEntryNew.getPath())) {

				return false;
			}
		}

		// add the new sourceFolder at the 1st position.
		IClasspathEntry[] newCPEntries = new IClasspathEntry[cpEntries.length + 1];
		System.arraycopy(cpEntries, 0, newCPEntries, 1, cpEntries.length);
		newCPEntries[0] = pSourceEntryNew;
		jProject.setRawClasspath(newCPEntries, null);

		return true;

[flaite]

Eine plug-in Seite lässt sich schnell erstellen.
Dafür muss man das/die plug-ins erstmal in ein feature packen.
Die plug-in Seite ist dann eine Webseite (ein Geraffel aus xml, html, Bildern, die plug-ins als jars zum downloaden).
In Eclipse kann dann der plug-in User über help / software updates  problemlos updates beziehen.
Dies ist eine gute Lösung für das traditionelle Client-Server Problem: wie mache ich updates auf die clients.
Die Website (d.h. das von Eclipse erzeugte xml, html, jar-zum-download, bilder-Geraffel legt man auf einen html Server. Ich nehm für sowas Tomcat, apache, IIS, was-auch-immer gehen aber auch.
So ganz automatisch ist es bei mir für das update leider nicht gelaufen. Allen Beteiligten (plugin, feature, update-site) die neue Versionsnummer 1.0.1 beizubringen war nicht so einfach, ging aber nach einigen Kampf doch. Ich hab wohl noch etwas falsch gemacht. Egal.
In der update Seite kann man dann noch branding-Elemente und Lizenzbestimmungen angeben. Sieht dann wirklich ziemlich professionell aus. Und ich seh das eindeutig als eine Herausforderung für die Geschäftsführung. Den hiesigen Admin dazu zu motivieren, dass Eclipse plug-in Administration das DING überhaupt ist, fällt ein bischen schwieriger. Ingo glaubt eben leider nicht alles. 

[Mark³]

dieser Wust an Versionsnummern bringt mich immer zur Verzweiflung...

In meiner RCP-Anwendung habe ich anfangs versucht, Änderungen durch neue Versionsnummern zu dokumentieren. Leider kam ich schnell durcheinander mit den Versionsnummern für Plug-Ins und Products und welche Version nutzt das Product von meinem Plugin etc. Hier ist das alte Phänomen bei Eclipse zu sehen: Einige Dinge passieren automatisch, andere aber nicht, so dass man dann doch alle xml- und Manifestdateien etc. im Quelltext durchsuchen muss und überall die Versionsnummern angleichen muss.
Aus Anwendersicht möchte ich bei Änderungen im Quellcode einfach einen Dialog bekommen: Versionsnummer hochzählen? Ja/Nein. Vielleicht in Eclipse 4.0 !?

[flaite]

Ich hab
1 Feature
1 Plugin
Ich zähle beide parallel hoch.
Das Feature wird dann in der update-Site referenziert (und das feature referenziert das plug-in).

Wenn plug-in 1.0.1 bekommt, bekommt das feature auch 1.0.1
Das geht eigentlich.
Nur leider eben nicht wirklich automatisch. Vielleicht finde ich noch einen Weg.

Ein bischen ätzend ist, dass (für den Anfänger wie mich) bestimmte Sachen nicht einfach zu implementieren sind, obwohl es für die Anwender einfach aussieht. Z.B. soll jetzt ein Eintrag in der dropDown Liste nicht nur auf rechte Maustaste Projekt erscheinen sondern eben auch auf rechte Maustaste xml-Datei. Oder Rechte Maustaste .Java Datei. Oder rechte Maustaste Ordner. Jeder erzählt mir hier, dass das bestimmt sehr einfach zu implementieren ist. Ist es für mich aber leider z.Zt. nicht. Sieht nur einfach aus. Aber gut.

[Mark³]

bzgl. rechtes Maustastenmenü: Meinst du folgendes?

Code

// create context menu
MenuManager manager = new MenuManager();
Menu menu = manager.createContextMenu(viewer.getControl());
viewer.getControl().setMenu(menu);
manager.add(new UnrelateCiContextAction(viewer));

Dies ist der Kot um ein Kontextmenü einzubinden. So kannst du eine ganz normale Action einbinden.

[flaite]

Vielleicht so ähnlich oder ganz anders.

Ich hab die Kontextmenüs jetzt so: 

Code

 <extension
         point="org.eclipse.ui.popupMenus">
[...]
<!-- 1. -->
  <objectContribution
            id="com.eip.cbeed.programming.menu"
            objectClass="org.eclipse.jdt.core.IJavaProject">    
            <visibility>
            <and>
               <objectState
                     name="nature"
                     value="org.eclipse.jdt.core.javanature"/>
               <objectState
                     name="nature"
                     value="com.eip.cbeed.eipNature"/>
            </and>
         </visibility>
            
            <action
               label="Export Into Ergo Portal"
               icon="icons/notes.gif"
               class="com.eip.cbeed.interact.ExportToDominoAction"
               id="Project"/>     

        </objectContribution>

<!-- 2. -->

      <objectContribution
            id="com.eip.cbeed.programming.menu"
            objectClass="org.eclipse.core.resources.IFolder">    
           
            
            <action
               label="Export Into Ergo Portal 2"
               icon="icons/notes.gif"
               class="com.eip.cbeed.interact.ExportToDominoAction"
               id="Folder"/>     

        </objectContribution>
<!-- 3. -->
      <objectContribution
            id="com.eip.cbeed.programming.menu"
            objectClass="org.eclipse.core.resources.IFile">    
           
            
            <action
               label="Export Into Ergo Portal 3"
               icon="icons/notes.gif"
               class="com.eip.cbeed.interact.ExportToDominoAction"
               id="File"/>     

        </objectContribution>
[...] 
</extension>

       
   
Praktisch in 3facher Ausführung. Das oberste ist für rechte Maustaste/Projekt sichtbar, das 2. für rechte Maustaste/Folder und die 3. und letzte für rechte Maustaste/File.
Das funktioniert auch soweit. Das Problem ist nur, dass ich nur die erste Aktion schön verborgen bekomme für Projekte, die nicht EIP Nature haben. Bei den anderen Aktionen klappt das nicht. Die sind dann in allen Projekten sichtbar und das soll nicht so sein.

 
Diese 3 popup Extensions rufen jeweils automatisch die Methode dieser Klasse auf. Nach der ID (s. action.id im xml):

Code

public class ExportToDominoAction extends ActionResourceAction implements
		IViewActionDelegate, IWorkspaceRunnable {
[...]
public void run(IAction action) {
		LogHelper.logInfo("run(IAction action) called [action=" + action + "]");
		if (action.getId().equals("Project")) {
			
			
			project = getIProject(this.selection.getFirstElement());
			
		
			doExport();
		} else if (action.getId().equals("Folder")) {
			IFolder folder = (IFolder) this.selection.getFirstElement();
			project = folder.getProject();
		} else if (action.getId().equals("File")) {
			IFile file = (IFile) this.selection.getFirstElement();
			project = file.getProject();
			
		}

Noch nicht fertig, da nur der oberste if doExport aufruft (und da ist die Business Logik).

[Mark³]

das ist dann wohl eher anders bei dir...
ich habe während der Erstellung meiner Actions schon irgendwie mitbekommen dass es hier verschiedene Paradigmen gibt, wie man Actions einbindet. Das Ganze ist für einen aus der Krabbelgruppe wie mich dann doch alles sehr verwirrend. Zumal ich nur das RCP-Buch hatteund keins deiner Grundlagenbücher...
Aber eigentlich will ich mich auch gar nicht in diesen XML-Dateien tummeln sondern möchte die Actions mit Eclipse-Gui anlegen...

[flaite]

Meine Methode hat natürlich den Vorteil das ich gar keine view erstelle. Das sind globale extensions des popUp extensionPoints.

[flaite]

Aber eigentlich will ich mich auch gar nicht in diesen XML-Dateien tummeln sondern möchte die Actions mit Eclipse-Gui anlegen...

Es ist in plugins.xml. Dafür gibts ja auch eine GUI Maske.

[Mark³]

das zeigt mir wieder, dass man zwar viel erreichen kann, ohne alles komplett zu verstehen, für bestimmte Details dann aber doch ein fundiertes Hintergrundwissen erforderlich ist.
Wenn ich plugin.xml im Manifest-Editor öffne sehe ich viele Extensions (org.eclipse.ui.views, ...commands etc) aber keine Extension Points. Ich kann mir allerdings den Extension Point für org.eclipse.ui.views anzeigen lassen, wenn ich danach suche. Er erscheint aber nicht in der Ansicht 'All Extension points' des Manifest-Editors, weil hier dann offenbar nur selbst erzeugte auftauchen.
Wie gern würde ich mich mal richtig einarbeiten in RCP, momentan komme ich leider nicht dazu und muss mit meinem Halbwissen kämpfen...

[flaite]

Nur leider eben nicht wirklich automatisch. Vielleicht finde ich noch einen Weg.

Das geht jetzt. Wobei ich im site.xml des update site Projekts immer noch ein bischen manuell nachhelfen muß.
1. Schritt: Version Nummer des/der plug-ins im plugin.xml um 1 hochzählen. SPEICHERN.
2. Schritt: feature.xml des Features öffnen.
3. Schritt: In Feature.xml auf plug-ins Tab wechseln. Dort rechte Maustaste. Synchronize Version. Die Version der eingebundenen plugins zählt 1 hoch. Dann Version des Features selber im ersten Tab von feature.xml hochzählen. SPEICHERN)
4. Schritt: site.xml in update-Site Projekt öffnen. Hier alle Referenzen manuell auf die neue Versionsnummer ändern (jars, usw.). SPEICHERN.
5. Auf den ersten Reiter der site.xml wechseln. Site mit Maus highlighten. Build-Button drücken.

Fertig. So kann ich bei Bedarf innerhalb von 10 Minuten eine neue Version auf den Server bringen, den das Team dann in ihr Eclipse läd. Die müssen dann ihr Eclipse neu starten.

Bei manchen - zur Zeit für das Projekt zum Glück nicht wirklich kritischen - Themen rätsel ich noch rum. Zum Beispiel läuft die Verbindung von Infoboxen für den Anwender und Userinitiierte Prozesse über die (multithreaded) Job-Api nicht richtig. Da muß ich mal nachforschen.

Absolut positiv: Man bekommt überall Beispielcode. Z.B.: Dominiclipse - immerhin ein plug-in mit dem man laut Ben Poole problemlos Java Code aus Notes Agents nach Eclipse auslagern kann - ist openSource und ich habs mir den Source Code des Plug-ins in eins meiner Eclipse Installationen runtergeladen, weiss wie ich es debuggen kann, etc. (http://benpoole.com/weblog/200610031509).  Gleiches gilt für allemöglichen Eclipse-plugins (z.B. von Jboss) oder Rich Client Produkte (z.B. http://jlibrary.sourceforge.net/)

Gruß Axel

 

[flaite]

Jedenfalls macht die ziemlich lose plug-in Struktur die ganze Geschichte nicht einfacher.
Gestern hab ich ca. 6 Stunden benötigt um herauszufinden, dass ich aus Versehen einen Default-Konstruktor gelöscht habe.
Danach startete das plug-in zwar noch, warf aber bei absolut jeder Funktion einen Fehler.
Den Konstruktor habe ich mir aus einen Buch kopiert, so dass mir das wahre Ausmaß seiner Bedeutung nicht wirklich klar war.
Naja. Erfahrung sollte klug machen.
Aber solche Dinge passieren.

[flaite]

Nun hat auch aus meiner Sichtjemand seine Meinung bezüglich Lotus-on-Eclipse geändert, der in den letzten Monaten durch seine bekannt "fundierten Kritiken" an Lotus-on-Eclipse aufgefallen ist.
Ich spreche über den Stolz und die Zierde Südhessens.
http://vowe.net/archives/007886.html
Für mich geht aus dem Artikel hervor, dass ihm Insider bei ein paar Bembel Wein die Sache mal ein bischen klarer dargestellt haben. Vorher wars ihm einfach zu marketing-chifriert. Naja. Vielleicht ist dem guten Mann die Welt des Marketings einfach zu fremd.
Zu Lotus Expeditor:
http://entwickler-magazin.de/zonen/magazine/psecom,id,6,news,31786,p,0.html

[Mark³]

ich konnte keinen lesenswerten Inhalt in Vowes Seite finden. Da mach ich liebr weiter mit meinem RCP.
Ich rufe beim Starten erstmal einen LoginDialog auf, bevor ich die Workbench starte. Leider sind meine Controls nicht sichtbar im Popup...Ist sicher ein läppisches Anfängerproblem aber ich sehs nicht momentan...Falls ich nicht selbst drauf komme werde ich mal im Forum nachfragen ;-)

[flaite]

Ich schau mir soweit es meine Zeit zuläßt Plug-ins und RCP-Produkte von anderen Leuten an.
Interessant find ich z.Zt.:
Dominiclipse
http://www.domiclipse.com/
und das wesentlich größere JLibrary von Martin Perez u.a. oder besser y o
http://jlibrary.sourceforge.net/

[flaite]

Expeditor scheint ein extra-Lotus Ding auf Eclipse Basis zu sein. Open Source btw.
Eine gemeinsame, eclipse-technologie-basierte Anwendungsplattform für mobile und Desktopdevices wie es aussieht. 
Hoffentlich haben die sich damit nicht verstrickt 

[Mark³]

Lotus Expeditor 6.1 gibt es als Download in der Partnerworld. Ich lad das mal runter um zu sehen was das sein soll...
Ich dachte das wäre nur ein neuer Name für die Workplace-Geschichten??

[Mark³]

Aus der Hilfe:

Lotus Expeditor Version 6.1 ist der neue Name und die neue Version der früher unter dem Namen IBM WebSphere Everyplace Deployment vertriebenen Software

Das hätte man ja auch gleich sagen können...

[flaite]

Aber es bekommt eine ganz neue Rolle... glaub ich.
Es fehlen einfach in der IBM User community Leute, die dies k.r.i.t.i.s.c.h. und k.o.m.p.e.t.e.n.t. unter die Lupe nehmen.
Und eben nicht die business consultants, die sich technische geben, dann aber permanent von einem technischen Standpunkt unhaltbare Kritik äußern, um nach ein paar Bembeln Wein dramatisch umzukippen. In anderen Umgebungen geht die Kritik gegen kritikwürdige Punkte und zwar weil die Leute sich mit dem Gegenstand über den sie sich äußern wirklich beschäftigen. Ich brauch das. Ich kann nicht alles selbst zu Ende denken.
Es existieren genug Sachen allein in der Eclipse Plattform, die kritikwürdig sind. Davon soll hier in Folge (auch) die Rede sein.