Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino
eclipse plug-in Entwicklung: Kommt man da rein?
flaite:
Hi,
wir haben hier einen wirklich sehr konkreten Bedarf verschiedene Entwicklungsaktivitäten unter eine Plattform zu stellen.
Weil ich
- neu bin
- fest daran glaube, dass am Ende alles gut wird
- und ich ja schliesslich mittelfristig irgendwie meinen senior Status legitimieren will,
hab ich mich freiwillig als Eclipse-Plugin Entwickler gemeldet.
Eine große Klappe gibts nicht umsonst. Trifft man kühne Aussagen, so steht man immer in der Gefahr, dass sich im inneren Auge die Umwelt in eine Horde von Zombies transformiert, "und ist es fertig?" murmelt und einen selber immer mehr einkreist.
Deshalb habe ich in den vergangenen Jahren zunehmend Projektrisiken durch die Klassiker "echtes arbeiten" und "gute Bücher" bekämpft. Manchmal hilft das.
Für Leute aus dem Lotus-Notes Umfeld sind Eclipse-Plugins nicht unbedingt abwegig, zumal der angekündigte Hannover-Client auf Eclipse-Technologien beruht. Man sollte eine gewisse Afinität zu Java haben und es ist ein ziemlich "abstraktes Thema", soviel ist sicher.
Inhaltlich sind die Aufgaben bislang recht einfach. Das kann sich aber noch ändern. Wenn es gefällt, droht der Kunde möglicherweise mit einem Folgeauftrag.
Bisher sollen:
1. Eine Gruppe von mit einem Excel-File generierten xml Dateien per Knopfdruck und Festlegung des Speicherorts der von excel generierten Artefakte in ein Eclipse-Projekt (und damit natürlich auch in das cvs-System) importiert werden.
2. Im Eclipse Projekt soll man dann eine bestimmte Art von Java Klassen (Projekt-spezifischer Name: Prozess-Scripte) schreiben.
3. Die Inhalte der xml-Artefakte aus Excel und er Inhalt der Java Klassen sollen dann an bestimmte Felder von bestimmten Dokumenten einer per Konfiguration festgelegte Domino-.nsf eingefügt werden.
Eclipse wird so eine Art zentrale Entwicklungsoberfläche für die speziellen Java Files Prozesskripte und die xml Dateien. Die xml Dateien sollen auf Wohlgeformtheit und Validität geprüft werden. Um die Aufgaben xml-Engineering und Java Entwicklung selbst brauch ich mich gar nicht mehr zu kümmern, weil es dafür prima plug-ins gibt. Für einen Eclipse-Pug-in-Entwickler ist die Java Entwicklungs Umgebung (jdt) ist ja nix anderes als ein plug-in. Für xml Engineering gibts in den WebTools Erweiterungen und anderswo prima Tools. Auch für Entwicklungs-Versionierung und -Kolaborationsplattformen wie cvs oder subversion ist Eclipse prima bestückt.
Somit brauche ich mich nur noch auf sehr enge und einfache projektspezifische Aufgaben konzentrieren:
- Der Import von xml Dateien aus einem bestimmten Ordner im Dateisystem des OS.
- Der Export des Text-Inhalts von xml und .java Dateien in bestimmte Stellen einer bestimmten Notes-Datenbank.
In Folge ein paar Bemerkungen:
- wie es ist
- welche guten Knowledge-Ressourcen es gibt
- ob es Probleme gibt
- ob ich das empfehlen kann.
Gruß Axel
flaite:
Bin bislang sehr angetan von der ganzen Geschichte und scheine wirklich schnell brauchbare Ergebnisse zu bekommen.
In jedem Fall benötigt man ein gutes Buch.
Ich arbeite mit:
http://www.amazon.de/gp/product/3827322545/302-8239942-3268002?v=glance&n=299956&s=gateway&v=glance
Hab aber auch:
http://www.amazon.de/gp/product/0321228472/302-8239942-3268002?v=glance&n=52044011
(leider die leicht veraltete Version).
Das erste Buch ist sehr gut. In einer CD- gibts eine Menge an Beispielprojekten zu den einzelnen Themen (wichtig). Die Erklärung sind gut und der didaktische Aufbau - ich würd sagen - herausragend.
Erst ab Seite 197 wird mit der plug-in Entwicklung angefangen (vorher gehts über Eclipse aus Anwenderperspektive). Es beginnt mit einem komplexen aber gehaltvollen Übersichtsartikel bzgl. der erstmal zu verdauenden plug-in Architektur.
Im nächsten Abschnitt gehts um die - sagen wir - Frontend Klassen.
Dann folgt ein sehr wichtiges Kapitel über die Backendfunktionalitäten des Eclipse-Frameworks für plug-in Aufgaben (File Verarbeitung und Zugriff, Erweiterung/Manipulation des IDE Editors).
Als letztes dann noch ein Kapitel über -sagen wir - erweiterte Backendfunktionalitäten zum Erfüllen von nicht-funktionalen requirements (Diagnose, Responsivität, Internationalisierung, Performance Tuning, sowie speziales wie ActiveX/OLE/Swing Interoperabilität).
Ganz hinten gibt es dann noch ein Kapitel mit Schritt für Schritt Anleitungen. Leider beziehen sich 6 von 9 dieser Kapitel auf den Eclipse Anwenderteil. Die 3 Anleitungen für Eclipse Plug-In sowie Eclipse Rich Client Entwicklung waren sehr hilfreich. Da es auf der CD für die anderen Eclipse-plug-in Entwicklungs-Kapitel Beispielprojekte gibt, braucht man vielleicht auch nicht mehr.
Ich bin natürlich schon eine lange Zeit Eclipse Anwender. Auf jeden Fall erhöht aber dieses Entwickeln von plug-ins noch einmal das Verständnis von Eclipse. Aus einer Notes Perspektive kann dies für die Zukunft bspws. hilfreich für Fehleranalyse sein (Hannover basiert auf Eclipse).
Mit Hilfe des Buchs und vor allem auch der Beispiele scheine ich hier einen Großteil der Funktionalität in der Evaluierungsphase programmieren zu können.
Es scheint nun einfacher zu sein als es zunächst aussah.
Letztenendes ist ein Eclipse-plugin nix anderes als ein xml-File (plug-in xml) und ein paar Java Klassen.
eclipse rocks.
Gruß Axel
flaite:
Weiter aus der Reihe pimp-up-your-tool.
Es ist wirklich ziemlich logisch aufgebaut:
Eclipse ist eine Sammlung an Plug-ins. Plug-ins haben haufenweise extension points. Z.B. gibt es einen extension point für Einträge in Kontext-Menüs von Ansichten. Da dockt man in dem plugin-xml seines eigenen plug-ins an.
--- Code: --- <extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.core.resources.IProject"
id="de.axel.menu">
<action
label="Export Into Portal"
icon="icons/notes.gif"
class="de.axel.menu.ExportToDominoAction"
id="DirectAction"/>
</objectContribution>
</extension>
<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.core.resources.IProject"
id="de.axel.menu">
<action
label="Import ConfigBuilder Output"
icon="icons/excelzeichen.gif"
class="de.axel.ImportXmlArtefactsAction"
id="DirectAction"/>
</objectContribution>
</extension>
--- Ende Code ---
Es wird dann automatisch die run Methode der im extension xml Zeugs(oben) angegebenen class aufgerufen (de.axel.ImportXmlArtefactsAction). Diese Klasse muß noch 2 interfaces implementieren: implements IViewActionDelegate, IWorkspaceRunnable
Bei Guis und langläufigen Aufgaben, ist es oft gut die GUI und die langläufige Aufgaben (hier kopieren von files) in unterschiedliche Threads zu legen. Dafür gibts bei Eclipse extra Job Apis. Das ist einfacher als invokeLater() und invokeAndWait() in Swing. Für das rumhampeln mit Files gibts mit IFile, IResource, etc eigene Klassen. Bisher klappt alles.
Es ist in einem Aspekt auf jeden Fall sehr ähnlich wie Notes programmieren: Man programmiert auf Basis eines komplexen Produktes an wohl definierten Stellen ein paar Erweiterungen. Vom unterliegenden Produkt (Eclipse oder Notes) ist man sehr abhängig und beide haben sicher noch Tücken, die ich nicht kenne. Vorteil ist aber, dass man da im Idealfall nur noch seine eigene Businesslogik in etwas einklinkt, dass wohlgetestet ist, gut funktioniert, den Anwendern vertraut, usw.
Aber das weiss eh jeder.
Gruß Axel
flaite:
Die Erfahrungen bleiben weitgehend positiv.
Ein bischen ein gotcha war, dass man tatsächlich jedes genutzte jar im plug-in xml, Abteilung runtime anmelden muß. Bisher sind das.
--- Code: --- <runtime>
<library name="integration_tool.jar">
</library>
<library name="lib/dom4j-1.6.1.jar">
<export name="*"/>
</library>
<library name="lib/domingo-1.1.jar">
<export name="*"/>
</library>
<library name="lib/jaxen-1.1-beta-8.jar">
<export name="*"/>
</library>
<library name="lib/Notes.jar">
<export name="*"/>
</library>
</runtime>
--- Ende Code ---
Classloader Probleme in Java sind natürlich immer Sch... .
flaite:
Was z.Zt. ziemlich verwirrend ist, ist zu kontrollieren, wo meine extensions landen.
--- Code: ---<extension
point="org.eclipse.ui.popupMenus">
<objectContribution
objectClass="org.eclipse.jdt.core.IJavaProject"
id="com.ibm.jdg2e.resources.programming.menu">
<action
label="Import ConfigBuilder Output"
icon="icons/excelzeichen.gif"
class="de.aja.eip.integration_tool.interact.ImportXmlArtefactsAction"
id="DirectAction"/>
</objectContribution>
</extension>
--- Ende Code ---
Das wird zu einer rechte Maustaste Menüaktion auf Java Projekte. Genau wie ich wollte.
Dafür muss man aber erst mal wissen, wie extension class und Object class heissen. Und das hat jetzt 2 Stunden gedauert.
V.a. die Objectclass org.eclipse.jdt.core.IJavaProject find ich schwer herauszufinden. Weiss auch nicht, wo das dokumentiert ist. ???
ZUR Zeit behelfe ich mir damit, dass ich mir die plug-in xmls von mir bekannten plug-ins anschaue. Eclipse selbst ist mir noch zu verwirrend.
Es gibt jedenfalls Tonnen von extension points und object classes von object contributions, die regeln, wo sich meine Erweiterung reinpluggt.
Falls jemand dafür eine gute Doku kennt, immer her damit.
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln