Eclipse Magazin: Hallo Mike! Die erste Generation der Eclipse-Plattform (Releases 1.0 bis 2.1) war ja vor allem eine Integrationsplattform für Softwareentwickler. Die zweite Generation (Eclipse 3.x) führte die OSGi Runtime ein und öffnete Eclipse hin zu einem allgemeinen Runtime-Application-Framework. Wie würdest du den Schritt von 3.x zu Eclipse 4.0 charakterisieren?
Mike Wilson: Das wichtigste Design-Ziel von Eclipse 4.0 ist, die Entwicklungsarbeit mit Eclipse – sowohl was neue Plug-ins als auch den SDK-Code selbst angeht – einfacher und schneller zu gestalten, ohne wirklich jeden Aspekt der Eclipse-Interna verstehen zu müssen. Bei der Umsetzung dieses Projektziels wird es als Nebeneffekt natürlich auch einfacher, den Code in neue Richtungen zu lenken. Neu aufkommende Communities sollen schneller in die Arbeit mit Eclipse einsteigen können. Genauso soll es viel einfacher werden, neue Technologien in Eclipse einzubinden.
Eclipse Magazin: In deinem Blog "Eclipse has a Future" [1] erwähnst du, dass sich die Technologielandschaft und die Eclipse-Community seit Eclipse 3.0 verändert haben. Wie haben sie sich verändert und warum genügt uns die Eclipse-3.x-Entwicklungslinie nicht mehr?
Mike Wilson: Offensichtlich ist Eclipse 3.x ausreichend für die vielen großartigen Anwendungsbereiche, in denen Eclipse bis heute zum Einsatz kommt - und an dieser Stelle ist es vielleicht nochmals angebracht zu betonen, dass wir die 3.x-Linie auch weiterhin unterstützen und weiterentwickeln wollen, solange diese von unseren Anwendern eingesetzt wird. Doch die Welt steht nicht still, und wenn neue Technologieansätze auftauchen, müssen wir in der Lage sein, diese für uns zu nutzen. In Bezug auf die Technologielandschaft sehe ich uns vor folgende Veränderungen gestellt:
- Eine viel größere Akzeptanz von Rich Internet Applications (RIA) in Bereichen, die traditionellerweise von "souveränen" Anwendungen (d. h. Stand-Alone Desktop-Applikationen) dominiert wurden.
- Cloud Computing (wenn einmal der Hype abgeklungen ist und die reine Funktionalität zum Tragen kommt)
- Mehrsprachige Softwareentwicklung
- Embedded-Geräte mit genügend Leistung, um Modularität, Servicearchitekturen, Provisionierung etc. zu benötigen
- Multicore-Systeme
All diese Dinge (und ich bin mir sicher, man könnte hier noch viele weitere nennen) beschreiben wichtige Trends, auf die Eclipse reagieren können sollte. Der Punkt dabei ist folgender: Wenn wir in fünf oder zehn Jahren weiterhin von Bedeutung sein wollen, dann müssen wir beweglich genug sein, um jegliche neu aufkommende Technologie ansprechen zu können. Bei der sich verändernden Eclipse-Community greift eine ganz ähnliche Überlegung: Ein Teil der Community strebt danach, neue Problemfelder und neue Technologien in Eclipse zu integrieren, während ein anderer Teil eher darauf bedacht ist, Eclipse als ultra-stabile Grundlage für ihre Produkte zu erhalten. Ich glaube, die Community umfasst heute ein breiteres Spektrum als noch in den Tagen von Eclipse 3.0.
Eclipse Magazin: Wie wird Eclipse 4.0 in der Lage sein, die Einschränkungen von Eclipse 3.x angesichts der beschriebenen Herausforderungen zu überwinden?
Mike Wilson: Ich denke da an viele Möglichkeiten:
- Das modellierte User Interface und die Kontexte überwinden die grundlegenden Einschränkungen bzgl. Form und Aussehen der Workbench. Z.B. werden bisher feste Strukturen wie ein einzelner Editorbereich, Views und Editoren in separaten Stacks, Perspektiven in einem Bereich über den Views/Editoren etc. zu einer Sache der „Policy“ und nicht der Implementierung.
- Die Eclipse Application Services (die sogenannten "20 Dinge", d.h. eine reduzierte Untermenge von Kern-Services und APIs, mit deren Hilfe das Eclipse-Programmiermodell vereinfacht werden soll, siehe [2]) machen es möglich, Eclipse-Plug-ins auch in anderen Sprachen - nicht nur in Java - zu implementieren (wobei JavaScript hier den Anfang macht).
- Die Flexibilität der über CSS gestaltbaren Workbench erlaubt es, das Look-and-Feel der Workbench viel einfacher und mit einem größeren Variantenreichtum zu kontrollieren.
- Die Arbeiten am flexiblen Ressourcen-Modell heben einige der grundlegenden Einschränkungen auf bzgl. der Nutzung des Ressourcen-Layers in umfangreichen Systemen und erlauben eine bessere Kontrolle über die Struktur von Eclipse-Projekten.
Eclipse Magazin: Kommen wir zum Entwicklungsprozess von e4. Wer initiierte ursprünglich das Projekt? Wer sind die e4-Entwickler? Arbeiten Vollzeit-Committer an e4? Ist IBM die treibende Kraft?
Mike Wilson: Ich denke, der Eclipse-Projekt-PMC realisierte den Bedarf an "so etwas wie e4" – einem Projekt also, das die vorwärtsgerichteten, innovativen Arbeiten, die länger als ein Jahr in Anspruch nehmen würden, vom Hauptentwicklungszug trennt - bereits vor einigen Jahren. Das aktuell existierende e4-Projekt begann dann einige Monate vor der EclipseCon 2008 Gestalt anzunehmen (wichtige erste Meilensteine für das e4-Projekt waren die e4-Präsentationen auf der EclipseCon 2008 [3] ("Eclipse 4.0 (e4) Kick Off" mit Mike Wilson und "Eclipse 4.0" von Steve Northover, Jeff McAffer, Jochen Krause und Mike Wilson) und der darauf folgende E4 Summit in Ottawa, 22. bis 23. Mai 2008 [4]).
Was die Frage nach den e4-Entwicklern betrifft, so gibt es momentan ziemlich viele Committer – so um die 50, denke ich. Doch die meisten davon sind eher interessierte Beobachter, die die Arbeit zwar mitverfolgen, sich aber nicht aktiv an der Entwicklung beteiligen. Ich würde sagen, dass die Entwickler-Kerngruppe aus 15 bis 20 Personen besteht, die aus unterschiedlichen Unternehmen stammen. Einige davon sind Vollzeit-Committer im Eclipse-Projekt, mit Verantwortlichkeiten sowohl für die 3.x- als auch die 4.x-Linie. Andere arbeiten ganz normal in ihren Hauptjobs und investieren ihre Freizeit in e4.
