Dem wöchentlichen Veröffentlichungsrhythmus folgend hat die Eclipse Foundation einen neuen, fünften, Release Candidate für die Ende Juni geplante final von Eclipse 3.2 herausgegeben.

Der RC5 findet sich hier zum Download.

Auch wenn sicherlich nicht der Königsweg der Installation, funktioniert ein einfaches Drüberspielen der Archivs in das Eclipse Installationsverzeichnis, recht gut. Diese Methode aber evtl. besser nicht für die produktive Version nutzen…

Nachdem Google sein Web Toolkit WTK in einer Betaversion freigegeben hat, musste ich mir das Teil natürlich gleich mal ansehen. Das hier sind nur die ersten Eindrücke des AJAX Frameworks, weitere werden definitiv folgen, weil es ein feines Toolkit ist, an sich eines, was man sich herbei gewünscht hat.

Das WTK besteht aus Java Archiven, ein paar Kommandozeilen Tools, einem WTK Browser, verschiedenen Bibliotheken und einer Dokumentation. Einmal entpackt kann der geneigte Entwickler, ein installiertes Java vorausgesetzt, gleich die Beispiele betrachten oder sogar gleich ein Projekt starten.

Auch die Erzeugung von Gerüsten für Eclipseprojekte sind zwei Tools vorhanden, so dass man gleich mit seiner Lieblings-IDE loslegen kann.

Aber was ist das Google WTK nun genau?

Im Prinzip bietet es einen Java::Java-Script Compiler und einen Debugging Browser. Man hat eine Art HTML Template an dem AJAX GUI Elemente über bestimmte IDs eingebunden werden. Dann hat man seine Java Klassen, deren Hauptklasse ein von Google vorgegebenes Interface implementieren und schreibt seine AJAX Oberfläche in Java. Zu guter letzt kompiliert man die Javaklassen (wobei die mitgelieferte Run-Configuration für Eclipse hilft) und erhält dann eine Ansicht der vollständigen AJAX Seite, gestyled wird normal mit CSS.
Das Google Web Toolkit ist sehr clever, macht Spaß und ist eine Bereicherung für alle Entwickler, die mit Java-Script nicht allzu viel anfangen können. Statt in Java-Script mit minderwertigen Tools zu arbeiten, kann man in der möglicherweise besten Sprache entwickeln mit der Unterstützung aller guten Java Entwickler Tools. Das Konzept ist genial, es war noch nie so einfach AJAX Seiten zu coden, vorausgesetzt man steht mit Java nicht auf dem Kriegsfuß. Die Komponentenbibliothek ist sehr umfangreich und wird sicher noch wachsen – ist es doch momentan noch eine Beta Version.

Da die Information etwas schwer zu finden ist, hier der Hinweis, dass bei einer Standardverbindung von PHP an openLDAP nicht immer alles gelingt.

So werden bei der Suchanfrage “oder” (“|”) Verknüpfungen erlaubt, “und” (“&”) Verknüpfungen werden aber nicht immer richtig ausgeführt. Bsp:

$search = "(&(uid=$login)(userPassword=$passw))";

Abhilfe schafft vorher (nach ldap_connect) den Parameter

ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3) ;

mitzugeben.

So wird LDAPv3 verwendet, was im Zusammenspiel mit openLDAP eben vonnöten ist.

Mit Eclipse Monkey steht ein kleines aber sehr feines Tool zur verfügung, mit dem man die IDE oder auch die RCP mittels normalem Java-Script scripten kann. So erzeugt folgender Java-Script Schnipsel:

function main() {
var files = resources.filesMatching(".*.java");
var match;
for each( file in files ) {
file.removeMyTasks(  );
for each( line in file.lines ) {
if (match = line.string.match(/System.out.print(ln)? *(.*)/)) {
line.addMyTask( match[0] );
}
}
}
window.getActivePage().showView("org.eclipse.ui.views.TaskList");
}

für die Ausgabe aller Tasks aus den geöffnten Projekten im Task-View.

Da Eclipse Monkey auf der in Java geschriebenen Mozillo Rhino Java-Script Implementierung basiert und auch die Eclipse API angesprochen werden kann, gibt es für den kleinen Monkey kaum Grenzen.

Nur weil die jüngsten Release Candidates auf Eclipse.org nicht mehr angekündigt werden die kurze Erinnerung, dass nach nur kurz einer Woche der vierte Release Candidate vom kommenden 3.2er Release erschienen ist.

Der RC4 ist auch nicht in sonderlich viele Mirrors eingespeist und ist hier erhältlich…

Nachdem dem unrühmlichen Release von 5.1.3 und dem sofort darauf folgenden 5.1.4 Release war es ja mal ein paar Tage ruhig in der PHP Welt. So ruhig, dass ich dachte ich könne es ja mal wagen, die 5.1.4 zu installieren, aber Pustekuchen…

Nach der Installation (hier unter Windows) lud die oci8 Erweiterung nicht mehr. Und da 80% meiner Datenbankzugriffe auf Oracle gehen ist das mal mehr als mau, nämlich unbrauchbar. Wohlgemerkt bei gleicher php.ini und sonst auch völlig identischen Settings. PDO-Oracle geht jedoch, aber PDO ist mir noch ein Tick zu neu und unerprobt um damit zu arbeiten.
Unter Linux habe ich es nicht getestet (und werde es auch erstmal nicht tun, denn meine Zeit ist zu schade um final Releases zu testen) wäre aber an Informationen interessiert.

Und in 3 Monaten eine neue Version 5.2 … Wie wäre es erstmal mit einem besseren QM bei den minor Releases, dann klappt es irgendwann vielleicht mal mit laufenden Releases…

Nur so wird das nix

Weil es auf der Eclipse Projektseite ein wenig versteckt ist, nur der kurze Hinweis, dass es von Eclipse 3.2 den RC 3 als Kernstück des lang erwarteten Callisto Releases gibt. Der Hinweis auf den RC3 taucht leider nicht auf der Startseite auf, man findet ihn aber direkt hier. Der dritte Release Candidat enthält eine Unzahl von Fehlerbehebungen und ist der final Version schon sehr ähnlich.

Ich mag PHP ja wirklich ganz gerne und nutze es auch in passenden(!) Projekten, aber dann passieren so Sachen, die einen Zweifeln lassen:

Wieder einmal versteht es PHP, sich aus der Gemeinde der ernsthaften Programmiersprachen zielgerichtet zu entfernen. Nach dem Fiasko der Veröffentlichung um Version 5.1 hauen die Entwickler schon wieder einmal so richtig daneben.

Das Release 5.1.3 hatte keinen Tag bestand, ein extrem heftiger Bug erzwingt heute ein Update auf 5.1.4.

Gratulation, so kommt man aus der Fricklerecke sicher nicht raus und die oft beschworene Eroberung des so genannten Enterprise Segments bleibt wohl solange ein feuchter Traum der Gemeinde, bis man gescheite Prozesse bei der Weiter-Entwicklung und den Releases implementiert.

Ein Profilneurotiker von ez publish reichte damals aus um 5.1 weitgehend unbrauchbar zu machen, was jetzt hinter dem Fehler steht ist noch nicht klar.

Aber qualifizierte Teams und Prozesse müssen her. Es muss ja nicht gleich so was langwieriges wie der Java Community Process sein, aber doch etwas Struktur wäre angemessen. Und ein Mechanismus dass man die Diven unter den Committern und ihre persönlichen Animositäten untereinander unterdrückt oder kassiert.