DOPPELT SICHER! DOPPELT GUT...

Transkript

1 Plus CD! Paralleles Hosting Ihrer Website in zwei Hightech-Rechenzentren an verschiedenen Orten! Superschnell: Zukunftssicher: 210 GBit/s Anbindung! Mitarbeiter! 1&1 DUAL HOSTING VIELE PAKETE JETZT SCHON AB 0, /Monat* Dual Hosting gibt s nur von 1&1! Kein anderer bietet Ihnen georedundante Sicherheit und maximale Performance für Ihre Projekte. 1&1 DUAL PERFECT 6 Domains aus.de,.com,.net,.org,.at,.eu 5 GB Webspace UNLIMITED Traffic UNLIMITED Click & Build Apps uvm..de,.eu,.com,.net,.org,.at OHNE EINRICHTUNGSGEBÜHR! Weitere leistungsstarke 1&1 Dual Hosting-Pakete und tolle Sparangebote unter / / ab 0, In den ersten 3 Monaten, danach 9,99 /Monat.* 0, 29* /Monat im ersten Jahr Ausgabe 08/11 Deutschland 9,80 Österreich 10,80, Schweiz sfr 19,20 Eclipse & Java 7 OSGi und REST Eclipse Gyrex Schwerpunkt Testen Von Swing nach RCP/RAP & Maximal sicher: DOPPELT SICHER! DOPPELT GUT... >> Interpreter und Debugger für DSLs >> 93 eclipse magazin 1&1 DUAL HOSTING >> BONUSVIDEO AUF CD Was ist neu bei der Eclipse Rich Client Platform 4.0? von Kai Tödter Java 7 all inclusive! Fünf Gratisartikel zum Thema Java 7 OSGi und REST >> 22 CLIPSE E N I T R UPPO JAVA-7-S Architekturentwurf mit OSGi Declarative Services und REST Eclipse Gyrex >> 39 Platform as a Service für die eigene Cloud Von Swing nach RCP/RAP >> 31 Alle Infos im Heft! Portierung einer Swing-Anwendung nach Eclipse RCP/RAP SCHWERPUNKT TESTEN * 1&1 Dual Perfect 3 Monate für 0, /Monat, danach 9,99 /Monat. Einrichtungsgebühr 9,60. Domains im ersten Jahr.de,.eu 0,29 /Monat,.com,.net,.org,.at 0,99 /Monat, danach.de 0,49 /Monat,.eu,.com,.net,.org 1,49 /Monat,.at 1,99 /Monat. Einrichtungsgebühr entfällt. 12 Monate Mindestvertragslaufzeit. Preise inkl. MwSt. GUI-Tests für Web- und AJAX-Applikationen >> 67 Automatisierung modellbasierter Testszenarien Clever Testen mit Eclipse Jubula >> 58 >> 76

2 The Making of an Eclipse Project Magazin Waking up to EclipseLink The Making of an Eclipse Project Was steckt eigentlich hinter einem Eclipse-Projekt? Welche Entscheidungen sind zu treffen, welche Bedingungen zu erfüllen, wie läuft das alles? Das Eclipse-Jubula-Team berichtet in loser Folge über seine Erfahrungen beim Open Sourcing von Jubula [1]. Dabei geht es nicht nur um Technik, sondern auch um Strategien, Abläufe und schwierige Entscheidungen. von Zeb Ford-Reitz Hibernate musste raus. Und nur um Folgendes klar zu stellen, das Jubula-Team hat nichts gegen Hibernate. Wir haben im GUIdancer- Projekt fünf Jahre lang Hibernate als ORM-(Object-relational-Mapping-) Framework erfolgreich und (verhältnismäßig) glücklich eingesetzt. Aber als 90 Prozent des GUIdancer-Codes als Basis für das neue Eclipse-Projekt Jubula dienen sollte, musste Hibernate leider draußen bleiben. Warum? Eclipse-Projekte müssen unter der Eclipse Public License (EPL) veröffentlicht werden, und Jubula stellt hier keine Ausnahme dar. Hibernate selbst steht unter der GNU Lesser General Public License (LGPL), die inkompatibel zur EPL ist. Obwohl das unser Hauptgrund war, den gesamten ORM Layer der Applikation zu tauschen, gab es noch einen anderen Grund, den wir nicht ignorieren konnten. Bundles Was Eclipse unter anderem zur Rich Client Platform macht, ist die ausgereifte Plug-in-Architektur auf OSGi-Basis. Diese Architektur ist besonders sinnvoll, wenn man mehrere Bundles (oder Plug-ins) einsetzt, die ähnliche oder sogar gleiche Abhängigkeiten besitzen. In diesem Fall kann jede benötigte Bibliothek auch in Form eines Bundles an genau einer Stelle gelagert und gepflegt werden. Wenn die benötigte Bibliothek, in unserem Fall Hibernate, nicht als Bundle vorliegt, dann müsste man diese selber mit ausliefern: entweder als JAR im eigenen Bundle oder als ein selbstständiges Bundle. In beiden Fällen hebelt man die Plug-in-Struktur aus; die Entwickler anderer Bundles wissen nichts von dieser nicht standardmäßig gebündelten Bibliothek und werden sie daher nicht benutzen. Selbst wenn eine solche Abhängigkeit als Bundle realisiert werden kann, muss man wissen, wo dieses Bundle zu finden ist. Folgendes sollte dabei klar sein: Ein Eclipse-Projekt (das in der Regel aus Bundles besteht) ist leichter zu warten, wenn es auf andere Eclipse-Projekte (die ebenfalls aus Bundles bestehen) aufbaut, anstatt sich selber um solche Abhängigkeiten kümmern zu müssen. Des Weiteren freuen sich auch die Nutzer darüber, denn sie müssen keine zusätzlichen P2 Repositories einrichten, um das Bundle zu benutzen. EclipseLink Die Suche nach einem neuen ORM-Framework war kurz und schmerzlos. Ein Blick in das Eclipse-Ökosystem ge- Warum keine LGPL? Obwohl es generell bekannt ist, dass Eclipse-Projekte keinen LGPL- Code einsetzen dürfen (auch nicht als gelinkte Bibliothek), ist es auf den ersten Blick unklar, warum das so ist. Mike Milinkovich hat einen bündigen Blogeintrag zum Thema geschrieben [2]. Dort ist zu lesen, dass die Schwierigkeiten der Eclipse Foundation mit LGPL hauptsächlich in der Unterstützung der kommerziellen Ökosysteme liegen. Dürfte man in Eclipse-Projekten LGPL-Code verwenden, müssten Firmen bei jedem Einsatz von Eclipse-Code oder -Bibliotheken genau prüfen, ob diese im eigenen Produkt lizenzkonform eingesetzt werden dürfen. Die Risiken und der Aufwand dafür würden die Anzahl der Firmen, die Eclipse als Basis für ihr Produkt einsetzen, drastisch reduzieren. Dabei wird die Entwicklung von Eclipse-Projekten entsprechend komplizierter, und Mike Milinkovich nennt auch Fälle, bei denen diese Einschränkung eine Umsetzung als Eclipse-Projekt verhindert hat. eclipse magazin

3 Magazin The Making of an Eclipse Project nügt, um EclipseLink [3] als ORM-Ablösung für Hibernate ausfindig zu machen. EclipseLink ist seit 2005 ein Eclipse-Projekt. In dem Jahr veröffentlichte Oracle die Kernfunktionen ihres kommerziellen TopLink-Produkts als Open Source. Seitdem baut TopLink auf EclipseLink auf und bietet darüber hinaus erweiterte Funktionen an. Da klingt die Jubula-Geschichte schon fast wie ein alter Hut: Denn auch das Jubula-Projekt, das aus Basiscode von GUIdancer besteht, dient als Open-Source-Basis für seinen kommerziellen großen Bruder. Als Eclipse- Projekt erfüllt EclipseLink die beiden notwendigen Kriterien für Jubulas neues ORM-Framework: EclipseLink steht bereits unter der EPL. EclipseLink steht als fertiges Bundle im P2 Repository der Eclipse Foundation zur Verfügung. Das bedeutet, dass man kein weiteres P2 Repository einrichten muss, um Jubula z. B. in einer Eclipse IDE zu installieren. Und nicht nur das, Jubula spielt dadurch auch mit anderen Bundles, die EclipseLink benutzen, problemlos zusammen. Das EclipseLink Bundle wird in den richtigen Versionen an einer Stelle gelagert und gepflegt. Die formalen Kriterien waren somit erfüllt, die technische Umsetzung benötigt noch Etliches an Analyse und Planung. Embbeded Database: H2 Einerseits wäre ein ORM-Framework ohne eine relationale Datenbank so gut wie nutzlos. Anderseits musste es möglich sein, Jubula ohne Weiteres in einer Eclipse IDE zu installieren und auszuprobieren. Mit der H2-Datenbank [4] konnten wir eine integrierte, dateibasierte Datenbank mit Jubula ausliefern. Sinnvolle Standardeinstellungen für H2 sorgen immer noch dafür, dass viele Nutzer nicht sofort merken, dass sie überhaupt eine Datenbank verwenden. H2 ist im Orbit-Projekt [5] als Bundle verfügbar. Weitere Datenbanken Das Arbeiten mit weiteren Datenbanken ist erst möglich, wenn die entsprechenden JDBC-Treiber vorhanden sind. Da die Lizenzen für die Treiber aber nicht EPL-kompatibel sind und die Treiber daher nicht über eclipse.org veröffentlicht werden durften, sind wir auf den Markt gegangen: Eclipse Marketplace [6]. Im Eclipse Marketplace stellen wir ein Fragment mit JDBC-Treibern für drei übliche Datenbanken (Oracle Database, MySQL und PostgreSQL) zur Verfügung. Und jetzt kann ein Benutzer, sobald die integrierte H2-Datenbank nicht mehr genügt (z. B. weil er mit mehreren Kollegen am gleichen Projekt zusammenarbeiten will), ohne größeren Aufwand das Eclipse Jubula Database Drivers -Fragment vom Eclipse Marketplace holen, um mit seiner schon vorhandenen Datenbank zu arbeiten. Die Backend-Logistik war geregelt, nun konnten wir uns wieder auf die ORM-Umstellung konzentrieren. JPA EclipseLink implementiert das Java Persistence API (JPA) und ist sogar eine Referenzimplementierung. Hibernate bietet ebenfalls das JPA an. Das machte die Umstellung von Hibernate JPA auf EclipseLink JPA relativ überschaubar und schmerzlos. Die Umstellung von Hibernate (Codebasis von 2004 ohne strukturelle Änderungen) auf Hibernate JPA war deutlich komplizierter, passt aber nicht unbedingt in diesen Artikel. Allerdings gab es trotz reibungsloser JPA-Umstellung einige Stellen, wo JPA selber keine Lösung anbietet. Hier mussten wir tatsächlich Hibernate-spezifischen Code durch EclipseLink-spezifische Coden ersetzen. DDL Die meisten ORM-Frameworks können DDL (Data Definition Language) aus Sourcecode und Konfigurationsdateien generieren und anwenden, um beispielsweise initiale Datenbanktabellen zu erstellen, zu löschen oder deren Struktur zu ändern. Obwohl DDL-Generierung von vielen JPA-Anbietern unterstützt wird, bietet JPA selber kein API dafür. Demzufolge muss man das konkrete API des eingesetzten Frameworks verwenden, in unserem Fall EclipseLink. Jubula benutzt die DDL-Generierung, um den Installations- und Migrationsprozess von einer älteren Version auf eine neuere zu vereinfachen. Beim Verbindungsaufbau zur Datenbank wird von Jubula geprüft, ob einerseits die nötigen Tabellen vorhanden sind, und andererseits, ob diese auch die aktuelle Struktur besitzen. Fehlen Tabellen, so werden sie automatisch angelegt. Falls die entsprechenden Tabellen bereits vorhanden sind, aber von einer älteren Jubula-Version angelegt wurden, folgt eine automatische Migration auf die neue Tabellenstruktur. Die Idee dahinter ist, dass man kein Datenbankadministrator sein muss, um Jubula installieren und benutzen zu können. Die DDL-Generierungs-APIs für Hibernate und Eclipse- Link sind sehr ähnlich: Hibernate stellt die Klasse org. hibernate.tool.hbm2ddl.schemaexport bereit, während in EclipseLink die Klasse org.eclipse.persistence.tools. schemaframework.schemamanager verwendet werden kann. Beide Klassen haben jeweils Methoden, um Tabellen entsprechend zu einem bestimmten Objektmodell zu erstellen beziehungsweise zu löschen. Dementsprechend war es beinahe trivial, die DDL-Generierung auf Eclipse- Link umzustellen. Der einzige Haken war, dass die von Eclipse Link generierten Constraints zum Teil sehr unterschiedliche Bezeichner tragen als die von Hibernate generierten. Daraus hat sich der folgende Ablauf entwickelt: 1. EclipseLink kann bestimmte Constraints nicht löschen. 2. Da verschiedene Constraints noch in der Datenbank stehen, kann EclipseLink bestimmte Tabellen nicht löschen. 3. Da verschiedene Tabellen (mit der veralteten Struktur) noch beziehungsweise schon in der Datenbank 12 eclipse magazin 6.11

4 The Making of an Eclipse Project Magazin stehen, kann EclipseLink entsprechende neue Tabellen (mit der aktuellen Struktur) nicht anlegen. Seiner Spezifikation gemäß ignoriert EclipseLink alle Database Exceptions, die aus diesem Prozess entstehen. Das Problem fällt erst auf, wenn die Strukturunterschiede irgendwann später zu völlig irritierenden Fehlern führen. Dieses Problem haben wir gelöst, indem wir unseren Migrationsassistenten für das erste Release mit EclipseLink unter der Haube ausgeschaltet haben. Ab der nächsten Version ist diese Funktionalität wieder im Einsatz, und dann verschwindet das letzte Relikt Hibernates aus Jubula. Was hat man eigentlich davon? Jubulas Umstellung auf EclipseLink war ein notwendiger Schritt, um ein Eclipse-Projekt zu werden. Aber auch andere Eclipse-basierte Projekte können von solch einer Umstellung profitieren. Die Konfiguration, um im OSGi-Kontext zu laufen, wird vereinfacht, und die Unterstützung der Eclipse-Community (mit der Entwickler Eclipse-basierter Projekte bestimmt schon Kontakt haben) ist dabei auch nicht zu unterschätzen. Zusammen mit H2 kann man eine schlanke Persistenzlösung implementieren, die durch simple Konfiguration auch mit großen Datenbanken arbeiten kann. Letztendlich muss jedes Projekt für sich selbst entscheiden. Für diejenigen, die diese Umstellung vornehmen und vielleicht auch funktionale Regressionstests dafür einführen wollen, kann ich ein sehr gutes UI Test Eclipse Package empfehlen. Zeb Ford-Reitz ist Eclipse Committer im UI-Testautomatisierungsprojekt Jubula. Als Entwickler bei der BREDEX GmbH ist er seit 2006 auch am Jubulas kommerziellem großem Bruder GUIdancer beteiligt. Links & Literatur [1] Jubula Project Page: [2] [3] EclipseLink Project Page: [4] H2-Homepage: [5] Orbit Project Page: [6] Eclipse Marketplace: Anzeige Das Portal für Java, Enterprise- Architekturen und SOA. 13 eclipse magazin

5 Jetzt abonnieren! ECLIPSE 3 Jetzt 3 Top-Vorteile sichern! 1 Alle Printausgaben frei Haus erhalten Intellibook-ID kostenlos anfordern ( 2 Mit der Intellibook-ID kostenlos in der App anmelden und Zugriff auf alle Ausgaben des Eclipse Magazins erhalten (+ Bonusinhalte!) Zugriff auf das komplette PDF-Archiv mit der Intellibook-ID3