Maven Tycho. Google Guice. Mylyn für Modelle. 7. bis 11. November Eclipse meets. Plus CD! The Westin Grand München Arabellapark

Transkript

1 M Plus CD! JE TZ ER T N! 4.11 Deutschland 9,80 Österreich 10,80, Schweiz sfr 19, KE Neue Serie: The Making of an Eclipse Project eclipse magazin VO R The Westin Grand München Arabellapark Anmeldung und Informationen: Spring Tooling Maven Tycho Interstellar Thermonuclear War Mylyn NatTable Eclipse e4 7. bis 11. November 2011 EXKLUSIV AUF CD: Eclipse meets > Eclipse Jubula SPRING Automatisierte GUITests für Java- und HTML-Anwendungen > Eclipse Communication Framework 3.5 > NatTable 2.2 > Google Guice 3.0 > Scala IDE Maven Tycho >> 21 RCP-Anwendungen mit Maven 3 und Tycho bauen Google Guice >> 33 Dependency Injection bei der Eclipse-Plug-in-Entwicklung Mylyn für Modelle >> 79 Task-fokussierte Klassendiagramme mit Mylyn Interstellar Thermonuclear War Android-Spielewelt mit ECF und Google Wave 2-IN-1-KONFERENZPAKET! W-JAX buchen und die Business Technology Days gleichzeitig mitbesuchen! e4-tutorial >> 41 Eventhandling und Datenaustausch >> 57 >> 14

2 Magazin The Making of an Eclipse Project Aufzucht und Pflege eines Eclipse-Projekts The Making of an Eclipse Project Haben Sie sich schon einmal gefragt, was eigentlich hinter den Kulissen eines Eclipse- Projekts passiert? Welche Entscheidungen sind zu treffen, welche Bedingungen zu erfüllen, wie läuft das alles? Das Eclipse-Jubula-Team berichtet in der neuen Eclipse-Magazin- Kolumne The Making of an Eclipse Project über seine Erfahrung beim Open Sourcing von Jubula [1]. Dabei geht es nicht nur um Technik, sondern auch um Strategien, Abläufe und schwierige Entscheidungen. von Achim Lörke Was hat uns dazu gebracht, ein Open-Source-Projekt zu beginnen? Nun, es war nicht die Aussicht auf das nette Gefühl, mehrere Euro pro Jahr der Allgemeinheit zu vermachen. Wie bei der Mehrheit der Eclipse- Projekte standen hinter der Entscheidung durchaus kommerzielle Interessen. Bei der Vermarktung eines kommerziellen Produkts entstehen viele Zwänge, die mit dem Produkt und seiner Weiterentwicklung eigentlich nichts zu tun haben. Kunden machen sich Sorgen über langfristige Wartung, Verkäufe brauchen eine lange Zeit bis zum Abschluss und Etliches mehr. Schließlich stellt man fest, dass ein Werkzeug allein die Probleme des Kunden nicht unbedingt löst. Beratung und direkte Unterstützung bei Einführung und Weiterführung von Testprozessen sind viel wichtiger. Es war deshalb nur natürlich, dass wir, d. h. die BRE- DEX GmbH, zunehmend im Beratungsgeschäft für Die Eclipse Foundation hat eine schöne Grafik veröffentlicht, die gut auf den Werdegang der BREDEX GmbH angewendet werden kann (siehe Abbildung). Wir benutzen Eclipse seit vielen Jahren, haben über die Zeit etliche Contributions beigesteuert und unser kommerzielles Testwerkzeug GUIdancer [2] auf Basis von Eclipse RCP umgesetzt. Wir wurden 2007 Eclipse Solution Member, haben Stammtische und Demo-Camps organisiert und waren auf einschlägigen Konferenzen mit Vorträgen [3] vertreten. Damit haben wir uns wohl immer mehr der Stufe des Champions angenähert. Da wir von Anfang an vorhatten, mit dem GUIdancer-Team die Jubula-Entwicklung weiter zu betreiben, war auch der letzte Schritt für uns klar: Um unser Engagement zu dokumentieren, haben wir unseren Mitgliederstatus bei der Eclipse Foundation auf Strategic Developer Member [6] erhöht. Wir wollten damit klarstellen, dass wir in Zukunft den Bereich Testautomatisierung und Requirements Management im Eclipse-Ökosystem aktiv voranbringen wollen. Open-Source-Entwicklungsschritte 14 eclipse magazin 4.11

3 The Making of an Eclipse Project Magazin Testautomatisierung unterwegs waren. Um die Basis dafür zu verbreitern, reifte in uns die Entscheidung, den Löwenanteil unseres Eclipse-basierten Testwerkzeugs GUIdancer kostenlos zur Verfügung zu stellen und unsere Brötchen im Umfeld von Beratung, Erweitung, Wartung und Schulung zu verdienen. Durch unsere Mitgliedschaft in der Eclipse Foundation war dann klar, dass dieses Open-Source-Projekt unter dem Namen Jubula als Eclipse-Projekt starten sollte. Auch Open Source leistet sich Bürokratie Die Eclipse Foundation verfügt über klare Richtlinien für ihre Projekte. Werfen wir einen Blick auf die Anforderungen, die an ein neues Eclipse-Projekt gestellt werden. Als Erstes muss ein Proposal eingereicht werden, in dem die Projektziele beschrieben werden. In dem Proposal soll knapp und klar dargestellt werden, um was es sich beim vorgeschlagenen Projekt handelt (Background). Die Faustregel dazu lautet, dass fünf beliebig herausgesuchte Eclipse-Committer verstehen können müssen, worum es geht. Zusätzlich muss der Umfang (Scope) des Projekts definiert werden: Was gehört dazu, was bleibt außerhalb und wo gibt es eventuell Überschneidungen mit anderen Projekten? Ein wesentlicher Punkt ist auch das Zusammenspiel mit anderen Projekten im Eclipse-Katalog. Wie passt das Projekt zum bestehenden Ökosystem? Ist eine Kollaboration mit anderen Eclipse-Projekten möglich und angestrebt? Welche Vorteile würde das Projekt dem Ökosystem bringen, welche den Vorschlagenden? Da die Eclipse Foundation sich nicht als Halde für Open-Source-Projekte sieht, muss im Proposal auch schon erläutert werden, wie stark und in welcher Form sich die Vorschlagenden engagieren wollen. Dies beinhaltet natürlich im Wesentlichen die Angabe über die Anzahl der vorgesehenen Committer zum Projekt, aber auch Angaben zu Infrastruktur, Öffentlichkeitsarbeit sowie die Bereitschaft, im erweiterten Bereich des Projekts Mitarbeit zu leisten und/oder Leitungsfunktionen zu übernehmen. Schlussendlich soll das Projekt herstellerneutral sein. Es sollte sich auch nicht auf spezielle Betriebssysteme beschränken. Da Proposals häufig von einem oder wenigen kommerziellen Anbietern erstellt werden, muss begründet werden, warum das Projekt trotzdem herstellerneutral entwickelt werden kann. Zur Unterstützung des Projekts werden mindestens zwei Mentoren benötigt. Dies sind Mitglieder des Eclipse Architecture Councils, die dafür sorgen sollen, dass neue Projekte sich gut in das doch sehr komplexe System der Eclipse-Projekte einfügen. Rein formal braucht man die Mentoren erst nach der Project Creation, es ist aber doch hilfreich, sich schon vorher mit erfahrenen Leuten zu beraten. Eine Hilfestellung sind Proposals bestehender Projekte, die zeigen, wie man es richtig macht (oder machen Anzeige Durchstarten mit Scala Heiko Seeberger, Roman Roelofsen 200 Seiten, Softcover, Mai 2010 PRINT ISBN: Preis: 24,90 / 25,60 (A) E-BOOK ISBN: Preis: 16,00 NEU! Kaum eine andere Programmiersprache kombiniert derart elegant wie Scala die Vorzüge verschiedener Programmierparadigmen und ermöglicht gleichzeitig die vollständige Integrationsfähigkeit mit Java. Dieses Buch bietet allen Scala- Interessierten einen praxisnahen und zielgerichteten Einstieg. Dabei legen die Autoren den Fokus bewusst auf die Praxis der Softwareentwicklung, um dem Leser die Vorteile von Scala möglichst direkt näher zu bringen. Im Rahmen eines Fallbeispiels wird der gesamte Zyklus der Softwareentwicklung abgedeckt, vom Einrichten der Entwicklungsumgebung über Debugging bis hin zur Integration in Java-EE-Umgebungen. Weitere Informationen und Bestellmöglichkeiten finden Sie unter Unsere Bücher erhalten Sie auch in jeder gut sortierten Buchhandlung.

4 Magazin The Making of an Eclipse Project kann) [8]. Und natürlich helfen auch die Mitglieder der Eclipse Management Organisation (EMO), allen voran Wayne Beaton. Ein Proposal muss mindestens zwei Wochen öffentlich auf der Eclipse-Website ausgehängt werden [4]. Dazu muss man nur das als HTML-Dokument vorliegende Proposal an die EMO schicken. Parallel dazu sollte die Werbetrommel gerührt werden, um Interessenten und Mitstreiter zu gewinnen. Dies ist besonders dann relevant, wenn ein Projekt völlig neu beginnt. Sollte es sich nämlich zeigen, dass kein großes Interesse an dem Projekt besteht, kann ein Proposal auch formlos zurückgezogen werden was auch schon häufiger passiert ist. Projekte mit einer existierenden Code- und Nutzerbasis haben es hier natürlich leichter. Mittel zum Zweck sind Veröffentlichungen in Blogs, Zeitschriften, Konferenzen usw. Die Eclipse Foundation unterhält eigene Foren [9], eines davon (General/ Proposals) ist speziell für die Diskussion von Proposals vorgesehen. Ist man dann der Meinung, alles Notwendige getan zu haben, kann ein Creation Review [5] beantragt werden, der zurzeit formlos abläuft und normalerweise in einer Zustimmung endet. Auf die früher notwendige Dokumentation für den Review wird verzichtet, und ein wirklicher Termin mit Diskussion findet nur auf Wunsch statt. Dies ist die Folge des geringen Interesses der Community an Creation Reviews. Nach der Zustimmung zum Projekt fangen die ersten entwicklungsrelevanten Abläufe an. Committer müssen benannt und für alle Committer muss bestätigt werden, dass sie ihre Arbeit unter der Eclipse Public License (EPL) veröffentlichen dürfen. Die ersten Committer werden formlos aus dem Proposal übernommen. Hierzu hat der Project Lead die Möglichkeit, über eine Webseite Basisinformationen einzugeben. Die Committer müssen dann das Paper Work [10] einreichen. Der wesentliche Punkt hierbei ist die Verpflichtung, sämtlichen Code und alle weiteren Dokumente unter der Eclipse Public License (EPL) beizusteuern. Für angestellte Committer muss außerdem der Arbeitgeber der Verpflichtung zustimmen. Mailing-Listen, Foren, Webseiten und Projektdaten werden durch die EMO (Eclipse Management Organisation), hier speziell durch den Webmaster, eingerichtet. Die Mailing-Listen dienen im Wesentlichen der Kommunikation zwischen den Entwicklern. Jedes Projekt erhält auch mindestens ein Forum zur Kommunikation mit den Anwendern. Die Webseiten dienen als schnelle Übersichten zu den Projekten [1] und enthalten Links auf Mailing-Listen, Foren, Downloads, Dokumentation und alle anderen (mehr oder minder) interessanten Informationen. Bei fehlendem Interesse kann ein Proposal auch formlos zurückgezogen werden. Damit ist dann das Gerüst für alle weiteren Arbeiten erstellt. Notwendige Änderungen in Jubula Das Jubula-Projekt hat mittlerweile die beschriebenen Prozesse durchlaufen und befindet sich, wie alle neuen Projekte, in der Incubations-Phase bei Eclipse. Jubula umfasst etwa 90 % der Codebasis von GUIdancer. Alle Funktionen, die zur Erstellung und Pflege von automatischen Tests nötig sind, wurden veröffentlicht. Lediglich ein kleiner Teil der Funktionen im Bereich Reporting und Metriken wird kurzfristig einer Add-on-Version vorbehalten bleiben und ggf. später in Jubula aufgehen. Einige Teile von GUIdancer waren indes nicht EPLkompatibel. Diese mussten entweder entfernt oder geändert werden. Andere Teile können aus Lizenzgründen nicht im Jubula-Projekt direkt bereitgestellt werden, sondern über Eclipse Labs und GitHub. Mit technischen und organisatorischen Details dazu werden wir uns in den folgenden Beiträgen beschäftigen. Vorab möchten wir nur sagen, dass zwei Themen herausragend waren: Wir mussten das nicht EPL-kompatible Hibernate durch EclipseLink ersetzen und haben viel mehr Zeit als erwartet mit dem eigentlich trivialen Thema Logging verbracht. Doch dazu mehr beim nächsten Mal! Achim Lörke arbeitet in der Geschäftsführung der BREDEX GmbH [7]. Er ist der Project Lead für das Eclipse-Jubula-Projekt und vertritt seine Firma im Eclipse Board of Directors und anderen Eclipse-Gremien. Zusätzlich balanciert er die Interessen der Jubula- und GUIdancer-Entwicklung. Links & Literatur [1] Jubula Project Page: [2] GUIdancer: [3] Eclipse Events: [4] Jubula Proposal: [5] Reviewtermine: [6] Eclipse Membership: member/membershiptypes.php#strategic [7] BREDEX GmbH: [8] Eclipse HOWTO Project Proposal: Resources/HOWTO/Pre-Proposal_Phase [9] Eclipse-Foren: [10] Committer Paperwork: HOWTO/Nominating_and_Electing_a_New_Committer 16 eclipse magazin 4.11

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