Ich habe es ausprobiert. Im Rahmen eines meiner Projekte waren auch Softwareentwickler einer externen Firma bei uns im Hause und haben ihre Arbeit in einer Delphi-Umgebung durchgeführt. Angesprochen auf die Frage, was sie denn mit Eclipse verbinden würden, fiel zunächst das Schlagwort Java und gleich darauf IDE. Es scheint also wirklich so zu sein, dass viele Entwickler in Eclipse zunächst nur die Java-IDE sehen. Und vor ein paar Jahren stimmte das auch noch so ungefähr. Doch, und das muss man mit aller Deutlichkeit betonen, ging in den letzten Jahren eine solche Innovationskraft von Eclipse, der IDE, aus, dass viele eben auch auf die Technik dahinter schauen wollten. Immer mehr Entwickler bekundeten ihr Interesse nicht nur an der IDE, sondern wollten auch auf Grundlage ihrer Technologie arbeiten.
Von Plug-ins ...
Mit einem ersten innovativen Konzept in Eclipse 2.x, durch das sich die IDE um Zusatzfunktionalität erweitern ließ, ging es los. Auch wenn andere Entwicklungsumgebungen ähnliche Ideen längst mitbrachten, man denke nur an das Konzept der Add-ins in Microsofts Visual Studio, so ging von dem in Eclipse enthaltenen Plug-in-Mechanismus eine derartige Faszination aus, dass viele im Java-Lager von diesem Konzept so überzeugt waren, dieses in Verbindung mit der schlanken Eclipse-Runtime als Grundlage für ganze Anwendungsarchitekturen verwenden zu wollen. Die Entwickler bei Eclipse reagierten auf die Forderungen der Community und stellten ab Version 3.x mit einem radikalen Umbau ihrer Software und der Umstellung auf OSGi-Technologie schließlich die Weichen für die Eclipse Rich Platform (RCP). Seitdem ist auch die Java-Entwicklungsumgebung selbst „nur“ noch eine Rich-Client-Anwendung, bestehend aus einem Satz an Plug-ins, den so genannten Java Development Tools (JDT), die nun die IDE implementieren. Die IDE ist damit also genaugenommen nur noch ein möglicher Anwendungszweck, ein Proof-of-Concept wenn man so will, bei dem Eclipse-Technologie zum Einsatz kommt. Eine Technologie, die seitdem in unzähligen weiteren Projekten von vielen Firmen weltweit für ihre Anwendungsentwicklung erfolgreich eingesetzt wird.
… zum Ökosystem
Heute ist Eclipse zwar immer noch eine IDE, aber mittlerweile eben auch ein umfangreiches Ökosystem an Software geworden, das ein Sammelsurium verschiedenster Werkzeuge und Frameworks bereitstellt, mit dem Softwareentwicklung auf breiter Ebene möglich wird. Dabei ist es wichtig zu verstehen, dass dieses Portfolio an Werkzeugen nicht nur an die Zielgruppe der Java-Entwickler gerichtet ist, sondern mittlerweile auch andere Programmiersprachen wie C++, Cobol, JavaScript oder PHP berücksichtigt werden.
Aber, auch wenn man bei Eclipse bemüht ist, andere Sprachen ins Portfolio zu integrieren, liegen die Wurzeln nun mal in der Java-Welt und deshalb ist nach wie vor ein starker Bezug dazu nicht von der Hand zu weisen. Ein Blick auf die Webseite offenbart die ganze Breite des Ökosystems. So finden sich Werkzeuge für die Entwicklung von Unternehmensanwendungen mit Fokus auf Java neben IDEs für verschiedene Sprachen. Man findet Frameworks zur Entwicklung von Rich-Client-Anwendungen, Webanwendungen, ja sogar mobile Endgeräte werden mit den Projekten eRCP (embedded Rich Client Platform) und MTJ (Mobile Tools for Java) bedient.
Simultanrelease
Jedes Projekt im Eclipse-Universum lebt zunächst für sich. Unabhängig von den anderen verfolgt ein Projekt zunächst sein individuelles Ziel (z. B. im BIRT-Projekt das Reporting) und setzt seine Roadmap in unterschiedlicher Geschwindigkeit mit unterschiedlicher Mannschaft um. Im Eclipse-Ökosystem existiert nun eine Vielzahl solcher Projekte, die wiederum von Softwarehäusern in aller Welt verwendet und in ihre Produkte integriert werden. Oft ist es auch so, dass auch unterschiedliche Projekte aus dem Eclipse-Ökosystem integriert, verbaut und miteinander in Einklang gebracht werden müssen, sodass es in der Vergangenheit oftmals zu Versionskonflikten und Inkompatibilitäten einzelner Projekte zueinander gekommen ist. Um diesem Effekt entgegen zu wirken, entschloss man sich in der Eclipse Foundation schon recht früh, möglichst viele Projekte zu bündeln und deren Entwicklung dahingehend zu organisieren und zu optimieren, dass an einem bestimmten Termin ein großes Eclipse-Release mit möglichst vielen Einzelprojekten gleichzeitig veröffentlicht wird. Die Freigabe eines solchen Simulatanrelease zu einem Termin X ist aber nur ein Aspekt. Der wesentlich wichtigere Aspekt ist jedoch, dass dieses große Release bereits vorab auf Kompatibilität zueinander getestet wurde und dadurch insgesamt für mehr Transparenz gesorgt wird. Wer mehr darüber erfahren möchte, mit welchen Regeln ein solches Mammutprojekt gestemmt werden kann, der findet hier mehr zum Eclipse-Simultanrelease.
Am 30. Juni 2006 startete man mit dem Callisto-Release den ersten Release-Train bei dem 10 Eclipse-Projekte gleichzeitig veröffentlicht wurden. Ein Jahr später folgte unter dem Codenamen Europa ein erneutes Simultanrelease, bei dem bereits 21 Projekte gleichzeitig und aufeinander abgestimmt veröffentlicht wurden. Bei der dritten Neuauflage im Jahr 2008 schafften 23 Projekte den Sprung ins Sammelrelease. Gut gelungen war in diesem Jahr auch die Aufteilung und Zusammenstellung einzelner Projekte zu spezifischen Distributionen je nach Anwendungszweck. So bot man im Rahmen dieser als „Ganymede“ getauften Simultanveröffentlichung speziell abgestimmte Eclipse-Versionen, beispielsweise für die JEE oder RCP/Plug-in-Entwickler an. Sieben unterschiedliche Distributionen waren es insgesamt, die Ganymede im Jahr 2008 an den Entwickler brachte und die im Eclipse-EPP-Projekt konzipiert, zusammengestellt und gepflegt werden (siehe: 2008 – Odyssee im Weltraum).
