Neue Serie: Eclipse plug-ins im Praxis Test

[flaite]

So, nachdem jetzt die Apperitiv-Schlürfer von der Computer-Woche Eclipse plug-ins hypen, hab ich mir überlegt, dass ich mir da einfach ein bischen mehr Mühe geben könnte.

Ich werde also verschiedene Plug-ins und Erweiterungen auf die Tauglichkeit hin überprüfen. Der Maßstab ist meine Interpretation von "Praxis-Einsatz". 

Disclaimer: A fool with a tool still is a fool (oder so ähnlich).
Der obige Satz ist imho sehr wahr. Eclipse-Plug-Ins sind kein silver-bullet, mit dem man plötzlich wer weiss wie produktiv wird. Sie können aber den Sachkundigen bei der Arbeit unterstützen. Jemand, der zu faul und uninteressiert ist, um sich die zugrunde liegenden Mechanismen verständlich zu machen, wird gerade mit plug-ins mitten in Lala-Land enden.

Ich werde in der Folge ein paar Eclipse plug-ins testen und hier berichten. 

1. Omondo plug-in für UML

Ich beginne mit dem Omondo UML plug-in, dass nun angeblich tatsächlich Reverse-Engineering Fähigkeiten hat.

a) Installation: verlief reibungslos:
- Ich hatte die entsprechenden Versionen (waren sogar noch Zusatzplug-ins vom Web-Tools Projekt sowie ein plug-in für Springframework-Entwicklung in der Eclipse Version, wo ich das reininstalliert habe, drin.
- Eclipse Menü: Help/About Eclipse SDK/plug-in Details meldete: KEINE FEHLER 

b) Dokumentation: Ein 517 Seiten langsames PDF mit vielen Screenshots scheint die Hauptdokumentation zu sein.

c) Tests
i. Reverse Engineering (dh: automatisches Generieren von UML-Diagrammen aus meinem Code):

Rechte Maustaste auf ein bestehendes Projekt. UML/Reverse Engineering.
Dialog 1-> Source Folder auswählen (ich hab eigene SourceFolder für Config-Dateien und für Unit-Tests. Hake nur den reinen Source Code an. (Auswahl ist sinnvoll).

Dann wurde ich darüber informiert, dass Bytecode Analysis nur mit Osmodo Pro geht. Ich weiss gar nicht was das ist, aber egal.

Es folgt ein längerer Prozess (dauerte genau so lange wie Zug 30 und Zug 31 des gleichzeitig auf KGS übertragenen Go Europameisterschaftsmatches Shikshina-Shilt (also ca 15 Minuten, lol).

Ich bekomme nun mehrere Diagramme, die ziemlich schick aussehen.
Zunächst hat das gute Stück mir ein Eclipse Package Dependency Diagramm generiert.
(s. Attachment Nr 1).
Erinnert mich schmerzhaft daran, dass meine neue Strategie nicht mehr so viele verschiedene Packages zu benutzen vermutlich ein bischen übertrieben ist.

Egal. Hier ist das gute Stück. Ich kapiere nicht ganz, warum es kein implements-Pfeil von de.aja.fussi.dao.ibatis nach de.aja.fussi.dao gibt, weil eigentlich jede Klasse in de.aja.fussi.dao.ibatis ein Interface aus de.aja.fussi.dao implementiert. Aber egal.

Daneben verspricht der Kontextmenü-Punkt "open" eine Menge wesentlich interessanterer Diagramme, die mir dieses Gratis-Tool generiert hat:
- Class Inheritance Explorer
- Class Dependency Explorer
- Class Association Explorer

Ich hab bisher keine Zeile Dokumentation gelesen und find das sehr cool.
Ich hab mal den Class Dependency Explorer geöffnet. Auch der scheint <<implements>> nicht darzustellen. Trotzdem bringt mir das ein mehr an Übersicht in diesem Projekt.
Nicht optimal. Aber so bekomme ich Eigenschaften und Methoden von verschiedenen meiner Klassen sowie ihre Assoziationen angezeigt, ohne dass ich mich sonderlich anstrengen mußte.
(s. Attachment 2).
Ausserdem hat alles funktioniert (d.h. keine Errors zwischendurch).

PRAKTISCHER NUTZEN:
Ich brauchte nichts zu tun, um mir Class Diagramme von meinem Code zu erstellen. Nur einen Knopf drücken und es war da. Class-Diagramme sind natürlich nicht alles. Sequenz Diagramme verschaffen in vielen Situationen mehr Übersicht in einem multi-geschichteten Java-Projekt.
Was bringen mir also diese Class-Diagramme.
Nun ich habe eine bessere Übersicht.
Das funktioniert ganz ähnlich wie ein Lotus-Script Klassenposter.
Ich habe jetzt alle mehr oder weniger intelligenten Properties und Methoden meiner selbstgedrehten Klassen in einem Dokument als Übersicht.
Das hilft schon, um mir eine Überblick zu verschaffen, bevor ich den nächsten Use Case implementieren will.

d) Aktuelles Fazit: Dieses Tool wird erstmal nicht de-installiert und es hat sich dafür qualifiziert, dass ich mir mal ein bischen das Doku-PDF durchlese.

Falls ich mal Zeit habe kann ich versuchen mit dem Osmondo Plug-In das Domain Modell eines Mini-Projekts in UML zu modellieren. Und dann daraus Code zu generieren.

e) Funstuff:
1. Das gleichzeitig installierte Spring Nature Plug-In meldet sich jetzt immer mit dem Osmonod Splash-Screen. Das ist aber alles. Kurios, scary, bisher aber nicht bedrohlich. 

f) Was fehlt:
1. Automatisch generierte Sequenzdiagramme wären wirklich hilfreich.

Axel

[Thomator]

Hi Axel,

danke für den Überblick, so was ist schon mal interessant.

Du hast völlig recht, Sequenzdiagramme wären das wirklich Interessante.
So ein Klassendiagramm ist ja nicht schlecht, aber ich finde, das hier auch der Package-Explorer in Zusammenarbeit mit der Generierung von Javadoc gute Dienste leistet.

Aber wie gesagt, als Überblick wohl nicht so schlecht. Sollte sich noch irgendwo in dem Plugin ein Mini-Schalter für das Generieren von Sequenz-Diagrammen finden, dann bin ich einer der Ersten, die dat Dingen downloaden.

Thomas

[flaite]

Hier ist übrigens eine weitere Eclipse-plugin Liste in deutsch:
http://www.java-tutor.com/java/eclipse/plugin/eclipse-plugins.html

Ich habe jetzt XMLBuddy heruntergeladen und bin schwer enttäuscht. Vielleicht kann mich jemand anders von diesem Teil überzeugen. Mir hilfts leider überhaupt nichts. Ich dachte ich hätte da einen vernünftigen xml-Editor mit Baumstruktur für die zahlreichen xml Dateien meines Projekts (spring, ibatis, log4j). Ist aber nicht. Angeblich ist in WebToolsPlatform ein guter xml-Editor drin. Krieg da aber auch keine xml Dateien reingeladen. Vermutlich mache ich was falsch. Wäre dankbar, wenn jemand mal einen Hinweis geben könnte.

Gut ist codeSugar. (http://codesugar.sourceforge.net/). Das ist ein sehr kleines plug-in. Es hilft um die ziemlich nervigen
# equals()
# toString()
# hashCode()
Methoden zu erstellen. Ausserdem clone(). Aber clone() benutze ich nicht.
Alle diese Methoden sind Bestandteil von java.lang.Object. Da alle Java-Klassen letztlich von java.lang.Object erben, haben alle Java-Klassen diese Methoden.

Diese Methoden werden gebraucht, um Objekte von einer Klasse vergleichen zu können.
Z.B. habe ich beschlossen, dass 2 meiner StockDescription Objekte gleich sind, wenn der shortname gleich sind.
HashCode hängt damit zusammen. Alles hervorragend in der einschlägigen Literatur dargestellt.
Dies ist alles ein bischen kompliziert, wird aber oft benötigt.

Die Methoden werden nach Auswahl im CodeSugar Menüpunkt automatisch erzeugt:

Code

	/**
	 * Returns <code>true</code> if this <code>StockDescr</code> is the same as the o argument.
	 *
	 */
	public boolean equals(Object o) {
		if (this == o) {
			return true;
		}
		if (o == null) {
			return false;
		}
		if (o.getClass() != getClass()) {
			return false;
		}
		StockDescr castedObj = (StockDescr) o;
		return ((this.id == null ? castedObj.id == null : this.id
			.equals(castedObj.id))
			&& (this.longName == null
				? castedObj.longName == null
				: this.longName.equals(castedObj.longName))
			&& (this.shortName == null
				? castedObj.shortName == null
				: this.shortName.equals(castedObj.shortName))
			&& (this.version == castedObj.version)
			&& (this.price == null ? castedObj.price == null : this.price
				.equals(castedObj.price)) && (this.created == null
			? castedObj.created == null
			: this.created.equals(castedObj.created)));
	}

Die geht vermutlich auf alle public getter. Ich muss mir das dann nur noch zurechtschneiden (brauch nur Vergleich auf longname und shortname).

Code

	public boolean equals(Object o) {
		if (this == o) {
			return true;
		}
		if (o == null) {
			return false;
		}
		if (o.getClass() != getClass()) {
			return false;
		}
		StockDescr castedObj = (StockDescr) o;
		return ((this.longName == null
				? castedObj.longName == null
				: this.longName.equals(castedObj.longName))
			&& (this.shortName == null
				? castedObj.shortName == null
				: this.shortName.equals(castedObj.shortName))
			);
	}

Bei mit equals zusammengehörigen hashCode gehe ich ähnlich vor.

Code

	/**
	 * Override hashCode.
	 *
	 * @return the Objects hashcode.
	 */
	public int hashCode() {
		int hashCode = 1;
		
		hashCode = 31 * hashCode + (longName == null ? 0 : longName.hashCode());
		hashCode = 31
			* hashCode
			+ (shortName == null ? 0 : shortName.hashCode());
		
		return hashCode;
	}

Dieser ziemlich oft vorkommende code sieht wirklich nicht nach Spaß aus. Das macht dann das plug-in. Die Hintergründe muß man natürlich zumindest auf User-Ebene verstehen (hat was mit Collections zu tun).

ToString sollte man auch immer erzeugen. Wenn man sich mal ein Objekt im Logfile oder per System.out.println (schlechte Idee) anzeigen will, kann man hier bestimmen was dort angezeigt wird. Das erledigt auch das Plug-In.
Wie üblich werden die Eigenschaften dort aufgelistet:

Code

	public String toString() {
			StringBuffer buffer = new StringBuffer();
			buffer.append("[StockDescr:");
			buffer.append(" id: ");
			buffer.append(id);
			buffer.append(" longName: ");
			buffer.append(longName);
			buffer.append(" shortName: ");
			buffer.append(shortName);
			buffer.append(" version: ");
			buffer.append(version);
			buffer.append(" price: ");
			buffer.append(price);
			buffer.append(" created: ");
			buffer.append(created);
			buffer.append("]");
			return buffer.toString();
		}
	

Ich Idiot hab das immer von Hand gemacht.

CodeSugar ist klein und sehr praktisch.

Axel

[flaite]

Heute hat endlich Log4E seinen Weg in den Praxistest gefunden.
http://log4e.jayefem.de/index.php/Main_Page
Warum?
Ich war in dem FormulaToLotusScript Projekt zu faul log4j statements in den Code einzubauen.
Die sehen so aus, wie Logging Statements eben aussehen (Aufruf an Logger irgendwo im Code). Die nachträglich einzufügen ist sehr, sehr langweilig.

Nun habe ich dieses Plug-In (die pro-Version, ist aber sehr billig und hat 45 Tage Testperiode) in mein Eclipse runtergeladen, konfiguriert und gestartet (mit Doku lesen hat das 30 Minuten gedauert). 
Ergebnis:
Pro Klasse wird ein statisches logger Objekt erzeugt. Und zwar exakt so wie ich das auch machen würde:

Code

	/**
	 * Logger for this class
	 */
	private static final Logger logger = Logger.getLogger(TRoot.class);

Die Log-Statements werden im gesamten Projekt automatisch generiert. Zu Beginn von jeder Methode gibt es jetzt einen Loger-Call (und auch bei fast jedem return statement).

Sieht bei einem Anfang der Methode so aus:

Code

void addVariable(String variableName, TVariable tVariable) {
  if (logger.isDebugEnabled()) {
			logger
					.debug("addVariable(String=" + variableName + ", TVariable=" + tVariable + ") - start"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
		}

[...] my stuff [...]
	if (logger.isDebugEnabled()) {
			logger
					.debug("addVariable(String=" + variableName + ", TVariable=" + tVariable + ") - end"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
		}
}

Und das ist besser als ich das je gemacht habe. Und zwar richtig nach best practices. Das if (logger.isDebugEnabled()) bringt Performancegewinne, wenn in der Log4j Konfigurationsdatei für den Log-Level debug kein logging stattfinden soll.

Es gibt eine Menge Einstellungen. (Über Eclipse-Menü Windows/Preferences). Man kann auch Alternative Logging Frameworks verwenden (z.B. jdk-logging).
Bei der code Generierung wird angezeigt, wo Änderungen durchgeführt werden (Pro Version).

Wenn es mehrere return statements gibt, die nicht unbedingt am Ende der Methode stehen, dann kann das Teil kein Log-Statement generieren und sagt das auch und v.a. auch wo. Logging für return statements ist eh ein bischen umstritten und in den Einstellungen des plug-ins nur optional wählbar.

Logging wird praktisch in jedem Java Projekt verwendet und das Tool hilft bei dem langweiligen Einfügen der benötigten Statements.
Natürlich werde ich aus bestimmten Methoden logging wieder entfernen. Bei get und set Methoden wurden schon von vorneherein keine generiert. Aber das ist deutlich weniger Arbeit als den langweiligen code selbst zu schreiben.

Die Webseite des Plug-Ins stellt die benötigten Infos sehr übersichtlich dar.

Dieses Plug-in ist soweit ich weiss von einem deutschen Studenten geschrieben worden und der Mann scheint wirklich zu wissen was er tut. 


Ein Problem ist echt, dass dieses Ding einfach den Source Code eindeutig zu viel mit Log-Statements ausstückt. Man muß das glaub ich ein bischen selektiver anwenden. Kann man auch. Aber es gibt eindeutig ein zu viel an Log Statements wie  ich jetzt lerne.

Gruß Axel   

[flaite]

Nächster Praxistest: QuickREx von Bastian Bergerhoff. Dieses plug-in für das Erstellen von Regular Expressions erhält sehr hohe Ratings auf plug-in central und ist umsonst.

[flaite]

Nun: Die Hibernate Tools. (http://www.hibernate.org/255.html)
Hibernate ist ein relativ komplexes openSource Objekt-Relational-Mapping Tool. Ein O/R-Mapping Tool macht die Verknüpfung zwischen einem Objektmodell und einer Datenbank einfacher.
Man kann sich das ein bischen wie LEI vorstellen, nur eben viel durchdachter und von echten Profis entwickelt.
 
Hibernate stellt für verschiedene Aufgaben nun Eclipse plug-ins zur Verfügung.
Im Plug-in gibts eine brauchbare Doku, die in der Eclipse Hilfe als eigener Eintrag erscheint.
Um damit arbeiten zu können braucht man:
a) nicht ganz schwache Nerven (das Log meldet einige Error und manchmal funktionieren Sachen nicht, nach Eclipse Neustart dann aber doch und Rebuild/Refresh Project sind dein Freund  -> ist aber noch in beta)
b) gewisse Hibernate und auch Eclipse Kenntnisse

Die Funktionalität ist aber sehr umfangreich und generiert (nach ein bischen Kampf) vernünftige Ergebnisse. Das Tool generierte mir aus einem RDBMS Schema mit 6 Tabellen mit einer Menge Foreign Key Beziehungen alles was man für einen hibernate layer braucht:
- das hibernate config-file
- die mapping-files
- POJOs -> einfache Java-Klasse, die im Objektmodell die Daten aus dem RDBMS aufnehmen. POJOs sind sowas wie EJB Entity Beans (igitt) für die freie Welt.
- als Bonus noch Klassen für den DAO Access Layer.

Eingehende Tests ergaben nun, dass das alles funktioniert (die generierten Klassen bekommt man eh als java-source files)

Ausserdem gibts noch eine noch nicht so dolle aber funktionierende Oberfläche, auf der man mit HQL-Queries rumexperimentieren kann (HQL ist ein spezielles SQL für Hibernate).

Und ein extrem unübersichtliche  UML-Klassen Diagramm der POJOs (Ausschnitt s. screenshot). --> muß noch dran gearbeitet werden. Würde schon helfen, wenn man die Klassen verschieben könnte. Ist nicht.

Hibernate ist sehr verbreitet in Java-Land und EJB-3 (an dem gerade gearbeitet wird und das eine Art EJB-Revolution darstellt) übernimmt viele Konzepte von Hibernate.

Sollte sich jemand mal mit diesem Posterboy von openSource Java beschäftigen, kann man die Eclipse Tools nur empfehlen, wenn man diese ganzen mapping-Files, POJOs und DAO-Klassen schon mal von Hand erzeugt hat (sonst wird man vermutlich wahnsinnig).
Danach ist das aber ein sehr hilfreiches Tool, weil diese ganzen mapping-Files, POJOs und DAO-Klassen eben total langweilig zu schreiben sind und das Tool ziemlich vernünftig aussehenden Java Code generiert. Besser als ich ihn selbst geschrieben hätte.
Einzige Probleme:
- Es wird an ein paar Stellen Java5 Code generiert, obwohl ich das nicht angefordert habe und das ein Java1.4 Projekt ist
- Es gibt ein festes Binding auf JNDI, was ich auch nicht will.
Beides konnte aber leicht von Hand korrigiert werden. 

Gruß Axel   

[Mark³]

hier passt ganz gut der BPEL PM Designer von Oracle rein. Ich habe versucht, den berühmten GetHauptstadt-Webservice damit anzusprechen, leider hatte ich nicht die Zeit, mich so in das Tool einzuarbeiten, dass ich wusste, was ich tat.

Ich habe den Webservice in Notes als WSDL exportiert und diese Datei dann im BPEL Plugin von Eclipse importiert. Dort habe ich ein neues BPEL Projekt gestartet und als Partnerlink den Webservice eingebunden. Im angehängten Bild sieht man im Kästchen Hauptstadt_Domino den Webservice, zusätzlich sieht man die XML-Struktur, die man über den Befehl 'explore' aufruft. Zum Testen muss man den gesamten Prozess irgendwie auf einem BPEL Server veröffentlichen (den habe ich auch bei mir lokal installiert). Wie man allerdings das Ding ausführt und die Parameter fürs Testen übergibt habe ich noch nicht ausprobiert.
Im Prinzip werden von diesem Tool wsdl-Dateien grafisch dargestellt und grafisch bearbeitbar. Beim Speichern wird über Ant das Zeug kompiliert bzw. gebaut. Leider bekomme ich immer Fehler weil mein Namespace irgendwie unbekannt oder falsch ist, ich hoffe mich demnächst hier mal etwas mehr mit beschäftigen zu können, um auch zu wissen, was ich hier eigentlich tue 

Grob betrachtet kann ich mit diesem PlugIn jedenfalls diverse WebServices miteinander kombinieren und sogar eine gewisse Workflow-Funktionalität einbauen. Welche Rolle hierbei der BPEL Server (ein Java Applicationserver von Oracle) genau spielt ist auch noch offen. Vielleicht interessiert sich ja der eine oder die andere hierfür und testet das auch mal aus. Ein schönes Beispiel wäre das Nutzen des Amazon-Webservices (den kennt fast jeder) um ihn mit Domino zu koppeln. Ich habe z.B. eine Bibliotheksdatenbank, die über die ASIN (ISBN) die Buchdaten zu einem Buch bei Amazon nachlädt. Momentan läuft da einfach ein LotusScript, dies könnte man ersetzen durch einen Webservice auf Domino-Seite, der über BPEL mit Amazon gekoppelt wird. Natürlich sind hier erstmal keine Vorteile gegenüber der bisherigen Implementation, aber theoretisch ist das interessant...

[flaite]

BPEL ist eine standardisierter xml-Standard (eigenes Schema) zur Beschreibung von interaktiven Geschäftsprozessen. Für mich ist Geschäftsprozess nichts anderes als Workflows.
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
Die graphische Darstellung basiert also auf einer xml Datei, denk ich.
Namespace-issues können sehr komplex werden, gerade in Kontext von Webservices. Das hat mich auch schon bei wesentlich unkomplexeren Sachen als das hier zum Weinen gebracht.

AFAIK geht es auch darum, dass der Serveranbieter verteilte Services wie Transaktionen und Security bereitstellt.
Ich halte das auch für ein interessantes Thema, mit dem ich mich auch bald mehr hands-on beschäftigen werde. 

[Mark³]

das nächste PlugIn welches ich nutzen werde schreibe ich mir selbst 

Hat zwar nix mit Notes zu tun (AddOns für HP Openview Service Desk) aber der Notes Rich Client funzt genauso. Hab mir gerade ein Buch dazu bestellt (das obere von den beiden)
http://www.amazon.de/exec/obidos/external-search/028-6901985-5547745?keyword=rich+client+eclipse&index=blended&tag=marksdominosi-21&tag-id=marksdominosi-21&I3.x=0&I3.y=0&I3=Los

Mal sehen ob das hilft. Die Anwendung zum Laufen zu bringen war nicht so schwierig aber so Details wie globale Zugriffe auf eine Openview-Session oder Preferences einfach abrufen ist schwierig die optimale Lösung zu finden im Web...
Vielleicht kann ich ein paar Tips geben wenn ich weiter gekommen bin.