Ich freue mich schon auf das Projekt (weil ich das Projekt betreuen werde) und hoffe, dass sich ein Student/in dafür begeistern kann! Und freue mich vor allem darauf, dass ich “nur” erzählen muss, wie ich mir das vorstelle, und die Implementierung delegieren kann ;)

http://www.partmaster.de/de/jobs/praktikum_entwicklung_einer_eclipseerwe…

Nun habe ich aber viele Projekte in Subversion-Repos und kann die nicht einfach ersetzen, mal bietet Google kein Git an, mal braucht es noch ganz viel Motivation bei meinen Kollegen. Aber ein Anfang sollte gemacht werden. Und dabei half mir das “git-svn” Modul. Damit lässt sich sehr elegant mit Git (und lokalem Repository) gegen ein Subversion-Repo arbeiten.

Für meine IDE Eclipse gibt es auch ein eGit-Plugin, aber dieses kennt das “git-svn” nicht. Im Netz fand sich eine Beschreibung, wir man die Subversion-Projekte mit git-svn auschecken und in den Eclipse-Workspace integrieren kann. Die Lösung, die Plugins aus dem Workspace heraus zu kopieren und den Inhalt auszutauschen und so (lest es einfach), fand ich aber ziemlich fragil.

Und ich fand eine Verbesserung:

• Man legt den Workspace in Eclipse an und wechselt in einer Shell in das Workspace-Verzeichnis¹
• mit git svn clone checkt man das Projekt in den Workspace aus
• In Eclipse ruft man den Import-Wizard auf “Import > Existing project into workspace”
• Hier such man den Workspace als Quellverzeichnis aus und “importiert” das Plugin in den Workspace. Achtung: Den Knopf “Copy files” (oder so) nicht anklicken.
• Nun “Team > Share project …” aufrufen, Eclipse erkennt die vorhandene Git-Konfiguration und Klicken auf “Finish” reaktiviert die Git-Anbindung des Plugins.

Nun kann man weiter am Code arbeiten und lokal einchecken/commiten. Das Einchecken ins Subversion erfolgt dann weiterhin in der Shell mit git svn dcommit.

Insgesamt immer noch eine wackelige Behelfslösung und ich hoffe, dass eGit auf dem Wege zu Version 1.0 auch die native Unterstützung für spendiert bekommt.

Gleichzeitig habe ich mir vorgenommen, das ganze Projekt von Beginn an durch Tests abzudecken¹. Also habe ich ein paar Abende mit der SimpleTest-Dokumentation verbracht. Aber als es lief hat es so richtig Spaß gemacht, den Code funktionieren zu sehen. Dabei ist eine Mock-Implemetierung für den Trac-Connector entstanden, der die konkrete Implementierung für das Project-, Case Tracker-Modul (und hoffentlich auch bald Agilo ;)) erleichtern soll.

Ich habe die ganze Codebasis (also eine ganze Drupal-Installation mit ein paar Zusatzmodulen) auf github.com abgeladen². Mit

git clone git://github.com/DirkR/drupal-trac-xmlrpc-service.git drupal-trac

kann man sich das Projekt holen und inspizieren. Gerade installiere ich das Ganze auf meinem Webserver, dann sind Interessenten gern für Review und Kommentare eingeladen.

Nun werde ich mich an die Implementierung der Casetracker-Integration wagen, das stelle ich mir einfacher vor als das project.module …

Ganz ilfreich für ds Einarbeiten in das Projekt waren auch die Gruppen auf g.do:

• http://groups.drupal.org/services (wenngleich die Authentifizierung nicht so ausführlich beschrieben ist, wie ich es mir gewünscht hätte, sehr FLEX-lastig)

• http://groups.drupal.org/testing-and-quality-assurance — Klasse!

Der XMLRPC-Webservice bereitet ein paar Probleme: Eclipse erwartet mit seinem Trac-Client den Webservice am Pfad /login/xmlrpc, der Drupal-XMLRPC-Server kann jedoch nur /xmlrpc bieten. So habe ich noch ein URL-Alias von /login/xmlrpc auf /xmlrpc eingebaut. Komplizierter wird es bei der Authentifizierung. Trac erwartet HTTP-Basic Authentication (wie bei “normalen” Websites), der Drupal-XMLRPC-Service arbeitet mit generierten Schlüsseln. Da bleibt wohl nur, den Eclipse-Trac-Connector zu nehmen (liegt Open source vor) und die angepasste Authentifizierung einzubauen. Nicht so schön, aber nicht tragisch. Und realisierbar. Erstmal habe ich mir einen REST-Service als Schnittstelle vorgenommen, das hilft mir an der Eclipse-front nicht weiter, sieht aber technologisch interessanter aus.

Es bleibt spannend!

Update (09.01.2010):
Das Projekt ist umgezogen nach gitorious.org

—

¹ Testgetriebene Entwicklung ist einfach Klasse!

² Das trac_service-Module gibt es hier: http://github.com/DirkR/drupal-trac-xmlrpc-service/tree/1e3e4e15f2a264e3ea1fdd73a5ae1ea74f562bc8/sites/all/modules/trac_service

Aber nun zur Release: In dieser Version haben wir das Generieren der Konfigurationsdateien für den Obfuscator verbessert, da wir nun auch die in Extensions referenzierten Klassen ermitteln und von der Obfuskierung ausschließen können. Und dann haben wir die für eine Softwareanwendung unerlässliche Online-Dokumentation hinzugefügt.

Hier die offizielle Release-Meldung: http://obfuscate4e.partmaster.de/blog/version-0-7-0-released

Weiter geht es in Richtung Obfuscate4e 1.0!

Ich hoffe und wünsche mir, dass es in naher Zukunft einfach möglich sein wird, mit Eclipse tolle (eRCP?) Anwendungen für mein Nokia-Fon zu schreiben. Ich habe da sogar schon einen Kandidaten: RunPlan mit GPS-Unterstützung — (den hatte ich auf meinem Palm, natürlich ohne GPS) .

EPIC¹ ist eine hoch-frequentierte Seite:

It has over 1100 products listed and 60 service and training providers; gets about 140K+ unique visitors a month and generates about 150-200K click thrus to the sites of the listed products.

Mich freut das natürlich sehr, treffen sich dabei zwei Systeme, für die ich mich sehr begeistere!

—

¹ Für die Drupaler: EPIC ist für Eclipse so etwas wie drupalmodules.com für Drupal :)

Nachdem ich im September den Perl Aufbaukurs am ZGDV Rostock gehalten habe, ist nun wieder einmal das Seminar “Perl Grundlagen” dran (am 17. und 18.11.2008).

Wie auch beim vorangegangen Kurs werde ich auf die Kombination ActiveState Perl (Perl 5.10) sowie Eclipse setzen, diesmal mit dem Perl-Plugin E-P-I-C.

Anbei auch diesmal der PDF-Foliensatz des Kurses. Der Eclipse-Workspace mit den Übungen wird sicher folgen.

So habe ich mir ein kleines Skript gebaut, welches genau das erleichtert. Es liegt bei mir im Verzeichnis ~/bin/, die Applikationen werden entweder mit dem Paketmanager installiert oder liegen unterhalb des Verzeichnisses ~/Apps/.

Das Standard-Verhalten des Eclipse-Starters wird durch die Umgebungsvariablen

• $ECLIPSE_HOME (zeigt auf das Eclipse-Installationsverzeichnis, Vorgabe ~/Apps/eclipse),
• $JAVA_HOME (zeigt auf das Java JRE-Installationsverzeichnis) und

• $PROJECTS_HOME (zeigt au den Eclipse-Workspace, Vorgabe ~/workspace)

vorgegeben.

Hier die (minimalistische) Hilfeseite:

My universal Eclipse starter v0.2
Supports easy combination of JRE, Eclipse and workspace to
launch an Eclipse session
  -e DIR, --eclipse=DIR    The eclipse installation directory
                           (defaults to the contents of $ECLIPSE_HOME)
  -j DIR, --jre=DIR        The JDK installation directory
                           (defaults to the contents of $JAVA_HOME)
  -w DIR, --workspace=DIR  The workspace
                           (defaults to the contents of $PROJECTS_HOME
                           or ~/workspace)
  -v, --verbose            Print settings before launching eclipse
  -h, --help               This help

Und dann einfach Eclipse starten:

$ eclipse   # startet bei mir Eclipse 3.4 mit Java5 im Workspace ~/projekte
$ eclipse -e ~/Apps/eclipse-3.2 -j ~/Apps/j2sdk1.4.2_17 # startet 'ne alte Kombi
$ eclipse -w ~/another-workspace # nimmt E3.4, Java5 und einen anderen Workspace

Fertig.

In unregelmäßigen Abständen halte ich ja am ZGDV Rostock zwei Seminare: “Perl Grundlagen” und “Perl Aufbaukurs”. Und am 18. und 19.09.2008 war es wieder mal soweit – ein “Aufbaukurs” war angesagt.

Ich hatte mich nach dem leztzten Kurs dazu entscheden, den Abschnitt “Objektorientiertes Perl in 4 Stunden” rauszunehmen und durch einen Exkurs in die Themen “Testen” und “Erstellen einer Distribution” zu ersetzen. Da mir erst wenige Tage vor dem Kurs einfiel, dass ich ein Jahr zuvor die Agenda geändert hatte, war auf den letzten Drücker ganz schön was zu tun!

Aber es hat mir wiedermal viel Spaß gemacht, “meine” Kursteilnehmer schienen auch zufrieden. Und ich hoffe, den Leuten im Kurs mit Testgetriebener Entwicklung von Perl-Modulen so richtig den Mund wässrig geredet zu haben.

Und noch etwas war neu: Statt auf das Duo “Notepad und Kommandozeile” (die Kurse finden an Windows-PCs mit ActiveState Perl statt) habe ich Eclipse mit dem Perlipse-Plugin eingesetzt. Und auch das war eine gute Entscheidung. Wenngleich ich beim nächsten Mal auf E-P-I-C setzen werde – das ist doch schon weiter in der Entwicklung und bietet mehr Funktionalität (wie man sie als Plugin- und Java-Entwickler von JDT und PDE gewohnt ist).

Anbei der PDF-Foliensatz des Kurses und der Eclipse-Workspace mit den Übungen. Versprochen ist versprochen :-)

PS: Ich gehe aus einem solchen Kurs jedes Mal mit so viel Ideen und könnte meine ganze Skriptsammlung überarbeiten … :-)

Abhilfe schaffte das Einsetzen des Schalters -dontusemixedcaseclassnames in der Proguard-Konfiguration, und schon macht Proguard bei der 27. Klasse eines Packages mit "aa.class" weiter. Das sollte m.E. Voreinstellung sein!

Einen interessanten Workaround fand ich bei http://osdir.com/ml/java.sun.kvm/2003-09/msg00083.html :

If you have more than 26 files,create another package and place the rest 26 files and so on.

Klasse!