Suche
Neues aus dem Land der Sonnenfinsternis

Eclipse Weekly: Die Community über Eclipse Two, Namensfindung für Eclipse Oxygen+1 und Buildship 2.0

Dominik Mohilo

© Shutterstock.com / solarseven

Die letzte Woche im Juni 2018 ist ein Datum, das man sich als Eclipse-Nutzer durchaus im Kalender anstreichen kann. Dann nämlich wird das Folge-Release zu Eclipse Oxygen aller Voraussicht nach veröffentlicht werden. Bereits heute, eineinhalb Jahre vor dem geplanten Release, diskutiert die Community über den Namen, den die Entwicklungsumgebung dann tragen soll. Auch über Eclipse Two, das bis dahin möglicherweise als ernsthafte Konkurrenz gelten könnte, wird im Moment viel gesprochen. Wir haben unsere Ohren gespitzt und einmal mehr Mäuschen gespielt…

Eclipse Pluto oder Eclipse Perseids

Eclipse Oxygen ist nicht einmal veröffentlicht und die nachfolgende Version noch eineinhalb Jahre entfernt. Dennoch macht sich die Community schon Gedanken über einen Namen. Bereits in der Vergangenheit gab es diesbezüglich einige Reibung, allerdings sieht es aktuell so aus, als würde am Konzept eines Codenamens für Eclipse vorerst festgehalten werden.

Chris Aniszczyk vom Planning Council der Foundation hat bekannt gegeben, dass noch bis 20. Januar Namensvorschläge aus der Community erbeten werden. Anschließend findet ein Vote für die Community statt und am 15. Februar wird das Planning Council den endgültigen Namen verkünden. Wer also noch ein Namensvorschlag anbringen möchte, der sollte sich beeilen und ihn in Bugzilla einreichen.

Eclipse Perseids – Make a wish! / Quelle: Matthias Sohn

Eclipse Perseids – Make a wish! / Quelle: Matthias Sohn

Die Liste an Namen, die bislang in die Diskussion eingebracht wurden, ist lang. Von Proton über Plasma bis hin zu Polaris und Potassium sind zahlreiche Namen vertreten. Allerdings gibt es zwei Vorschläge, die bisher eine klare Favoritenrolle einnehmen: Pluto und Perseids. Diese Namen knüpfen an die astronomisch angehauchten Projektnamen wie Luna, Mars und Callisto an. Die aktuellen Versionen (Neon, Oxygen) haben zwar auch einen wissenschaftlichen Hintergrund, gehen aber ein wenig weg vom „klassischen“ astronomischen Schema.

Auch das Namensschema, das auf dem Erscheinungsjahr basiert, wird immer mal wieder angebracht, aber auf einen richtigen grünen Zweig kommt man dabei nicht. Wie oft angemerkt ist das Erscheinungsjahr leicht missverständlich, denn das jeweils dritte Minor Release einer Eclipse-Version erscheint ja nicht im gleichen Jahr wie das Major Release, sondern im darauffolgenden.

Kritik für den Namen Pluto gibt es, da der Zwergplanet, wie bekannt ist, den Status als „vollwertiger“ Planet verloren hat. Dementsprechend könnte man diese Namenswahl als Herabwürdigung von Eclipse gegenüber den anderen, großen „Planeten“ (IntelliJ IDEA, NetBeans) interpretieren. Perseids wäre als Name allein schon deswegen passend, weil kurz nach dem Release dieser Meteorstrom auch 2018 wieder am Nachthimmel sichtbar sein wird.

Vielleicht wird sich die Community aber auch für den chemischen Ansatz entscheiden. Dafür kämen dann die Namen Platinum, Phosphorus, Plutonium, Polonium oder Palladium in Frage. Eher weniger ernstgemeinte Vorschläge dürften Eclipse Phasor, Eclipse Picard, Eclipse Phantom Menace und Eclipse Planet sein.

Für welchen Namen sich die Community letztlich entscheiden wird, steht – man verzeihe mir das Wortspiel – natürlich in den Sternen.

Eclipse Two: Das sagt die Community

Rund drei Wochen sind ins Land gezogen, seit Doug Schaefer auf seinem Blog die Arbeit an Eclipse Two angekündigt hat. Wir haben über diese spannende, neue Entwicklung berichtet und den Veteran aus dem Eclipse-Universum zum Interview gebeten. Doch nicht nur uns sind Dougs Bemühungen aufgefallen, das „Eclipse der Zukunft“ zu erstellen, auch die Community diskutiert auf GitHub, unseren Portalen und Dougs Blog über die neue IDE.

Eine dabei immer wiederkehrende Frage ist, worin sich Eclipse Two denn von Eclipse Orion, Eclipse Che und Microsofts Visual Studio Code unterscheide. Bei dem Wort Browser-IDE oder Web-IDE kommen einem natürlich genau diese drei Vertreter sofort in den Sinn. Hierzu hat Doug Schaefer eine ziemlich eindeutige Meinung:

Der Hauptunterschied ist, dass Eclipse Two keine Server-Komponente hat. Alles ist lokal auf dem eigenen System, wie es auch bei der “klassischen” Eclipse IDE der Fall ist. Für die Nutzung ist es nicht nötig, Zeit von Cloud-Service-Providern zu mieten, einen eigenen Server zu unterhalten oder Docker zu installieren. Es ist eine herkömmliche Desktop-Anwendung, die eben mit Web-Frontend-Technologien und JavaScript-Bibliotheken erstellt wurde, welche auf das lokale System sowie auf verteilte Server zugreifen können.

Für ihn sei Eclipse Two, so stellte er fest, keine Web-IDE. Es werden lediglich ähnliche Elemente verwendet. Doch gerade diese sind es, die manchen Nutzern gar nicht passen. Der Nutzer johnlemon kommentierte auf JAXenter.com „Stop this JavaScript hype!“ und Arnaud Masson setzte mit folgendem Kommentar nach:

I hope the „next 20 years“ of Eclipse will not be JavaScript 🙁

Andere freuen sich über den neuen Ansatz. Gerade die Tatsache, dass mit Eclipse Two kein Web-Editor wie VS Code sondern eine richtige Entwicklungsumgebung gebaut werden soll, macht das Projekt für einige sehr interessant. Doch auch die Richtung, die das Projekt einschlagen und welche Features es erfolgreich machen könnten, werden beispielsweise auf GitHub besprochen. Vlad Dumitrescu schreibt:

This is a cool initiative. However, if it’s going to be just another VSCode/Atom (given these are slowly becoming IDEs too), I’m not sure what the benefits are. What would Eclipse Two provide that others can’t/won’t? What is wrong with the VSCode model that can be improved there? Can the existing Eclipse community’s experience be leveraged?

The real kicker would have been if it was possible to migrate existing Eclipse plugins to the new platform. Then one would not need to implement everything again and maintain two versions for several years, which is a major pain. Given that for example e4 has been the official Eclipse platform for something like 6-7 years and yet the IDE itself still doesn’t use it fully, it is clear to me that making people switch to a completely new platform will be very slow.

Über die Vorteile von Chromium und Electron schreibt hingegen Ned Twigg:

If Eclipse SWT had a high-quality Chromium embed, then this project could be done using the SWT/RCP stack. Plugins could choose to provide a webview or an SWT UI, allowing a migration over time. There has been some effort in that direction, but it would require a significant investment to become production ready.

On the other hand, I think there’s an argument to be made that eclipse’s core stack (SWT and p2) is struggling, while Electron’s is strong and getting stronger. So by focusing solely on Electron rather than building a bridge to Electron’s endpoint through SWT, the Eclipse community can shed those responsibilities and focus on the core value-add.

As a third-party RCP developer, I’m rooting hard for the first result. But for anyone starting a greenfield project, I would certainly recommend electron over the eclipse stack. So regardless of outcome, I think this project is a great way to check the competitiveness of the eclipse swt/rcp ecosystem. If EclipseTwo can build a capable ide platform from scratch before SWT can get a reliable chromium embed and/or per-platform theming, then that’s a good sanity check for whether it makes sense to mothball SWT or not.

NOTE: Yes, SWT already provides access to the native browser. The reason that a chromium embed is so critical is that it guarantees the exact same build of the exact same browser on all platforms. By shipping tens of megabytes of chromium binaries, you don’t have to worry about cross-browser or cross-platform UI testing nearly as much, which is currently a huge productivity advantage for the electron ecosystem over the swt/rcp ecosystem.

Zusammenfassend ist festzustellen, dass das Projekt derzeit durchaus für Wirbel sorgt. Natürlich werden wir die weitere Entwicklung genau im Auge behalten und halten es wie Antoine Thomas, Product Manager der Eclipse Foundation, der auf GitHub schrieb: „I am very curious to see what you can achieve with your project.“

Eclipse Neon.2 auf Maven Central

Auf dem Blog des Object Teams verkündete Stephan Herrmann unlängst, dass nun sämtliche, vom Eclipse-Projekt produzierte Neon.2-Artefakte auf Maven Central verfügbar seien. Hierdurch wurden einige Probleme beseitigt, die im fehleranfälligen Build-Prozess in Verbindung von Eclipse mit Maven auftreten können.

Durchgeführt wurde dieses Unternehmen mithilfe des CBI aggregators, einem Model-basierten Tool für die Transformation von p2-Repositories. Das Tool extrahiert die Metadaten eines p2-Repos und erstellt daraus die pom-Dateien. Keyfeature ist das Kopieren sämtlicher Abhängigkeitsinformationen, die in der Datei MANIFEST.MF vorkommen, in korrespondierende Deklarationen im pom-File.

Erhältlich sind bisher die Repositories für Eclipse Platform, Eclipse JDT und Eclipse PDE. Natürlich sind die Arbeiten noch nicht abschließend vervollständigt. So muss zum Beispiel die Bearbeitung von Fragmenten noch verbessert werden. Derzeit gibt es ungefähr 300 Artefakte, für sämtliche Artefakte der Projekte des Simultaneous Release werden allerdings über 7000 benötigt, es ist also noch eine Menge zu tun.

Informationen darüber, welche Arbeiten noch zu erledigen sind und genauere Hintergründe der Aktion gibt es auf dem Blog des Object Teams.

Buildship 2.0: Gradle-Support für Eclipse

Auch die abschließende News kommt diesmal aus dem Bereich der Build-Tools. Mit Buildship 2.0 veröffentlichte Gradle Inc. in der vergangenen Woche die neue Hauptversion ihres offiziellen Gradle-Toolings für Eclipse. Für die neue Version haben die Entwickler unter anderem die Benutzeroberfläche nach den Wünschen der Community überarbeitet. Es wurde dabei Wert darauf gelegt, das Design dem aktuellen Gerrit-Branding anzupassen und den Eclipse-Design-Richtlinien anzupassen. Icons sind nun auch für Menschen mit Achromatopsie unterscheidbar und fügen sich gut ins Dark Theme ein. Für hochauflösende Displays wurden die Grafiken angepasst.

Das neue Design von Buildship / Quelle: Gradle Blog

Das neue Design von Buildship / Quelle: Gradle Blog

Noch wichtiger ist aber die ab Buildship 2.0 verfügbare Unterstützung für Composite Builds. Diese erlaubt es Nutzern, verschiedene Gradle-Builds zu verwalten als wären sie ein großer Multi-Projekt-Build. Der Vorteil: Der Zeitaufwand wird deutlich geringer, da es ab sofort möglich ist, mehrere Projekte, die normalerweise eigene Projekte sind, gleichzeitig zu bearbeiten. In einem Blog-Post erklären die Macher von Gradle genau, wie Composite Builds funktionieren.

Auch neu sind der Offline-Modus und die genauere Projekt-Synchronisation. Ist der Offline-Modus aktiv, erhalten alle Invocations von Gradle das Argument --offline. Bei der Projekt-Synchronisation kam es durch das Fenster mit der Frage, ob die Descriptors geupdated oder gelöscht werden sollen, das beim Import von Projekten aufging, häufig zu Fehlern. Weist die vom jeweiligen Projekt genutzte Gradle-Version gewisse Attribute auf, wird sie komplett und automatisch überschrieben. Manuell eingebaute Modifikationen werden dabei nur dann beibehalten, wenn keine Informationen über das jeweilige Attribut vorliegen.

Für Buildship wurde die Mindestanforderung auf die Versionen 1.7 von Java und 4.2 von Eclipse festgelegt. Weitere Informationen zur neuen Version gibt es auf dem Blog von Gradle, herunterladen kann man sich die neue Version der Gradle-Integration im Eclipse Marketplace.

Kaum eine Community ist aktiver und innovativer als die der Eclipse IDE. JAXenter hat das Ohr am Puls der Entwicklungsumgebung und berichtet wöchentlich über die neuesten Entwicklungen und die spannendsten Geschichten rund um Eclipse.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.