Neues aus dem Land der Sonnenfinsternis

Eclipse Weekly: Von neuen Versionsnamen, zu vielen IoT-Standards und zu wenigen Möglichkeiten für Android-Entwickler

Dominik Mohilo

(c) shutterstock.com / solarseven

Frühling ist ein Auslaufmodell und bald geht der Sommer wieder in Serie. Mit dem Sommer kommt das neue Update von Eclipse, Version 4.6, genannt Neon. Doch wird der für nächstes Jahr geplante Nachfolger, Eclipse Oxygen, überhaupt unter diesem Namen veröffentlicht? Die aktuelle Diskussion zu diesem Thema erhitzt die Gemüter…

Eclipse bald ohne Releasenamen?

Tracy Miranda, Gründerin der Kichwa Coders, hat mit einem heiß diskutierten Blogpost vergangene Woche das Eclipse-Universum aufgemischt. Sie schlägt darin vor, auf sämtlichen Seiten, mit denen User von Eclipse in Berührung kommen, auf die Releasenamen zukünftig zu verzichten.

Ihrer Erfahrung nach würden einige Entwickler lieber IntelliJ verwenden, weil sie das Versionsschema von Eclipse nicht verstünden. Dabei zitiert sie einen dieser Entwickler mit:

I never understand the different versions of Eclipse, you know, Luna, Mars, Neon – what does what, which is the Java one I should download? With IntelliJ it’s just IntelliJ community or ultimate, I know what to get.

Sie untermauert ihren Vorschlag, zukünftig Updates mit dem Jahr der Veröffentlichung zu „branden“, mit einem Artikel von Chris Grams über Markennamen von Open-Source-Projekten. In diesem plädiert Grams dafür, dass Marken sehr viel wirkungsvoller seien, wenn sie potentiellen Nutzern schon einen Hinweis darauf geben, was sie erwartet. Ein Tool für die Erstellung von Widgets sei mit dem Namen WidgetMaker besser bedient als mit einem Namen wie Zopple.

In der zugehörigen Diskussion haben sich zahlreiche namhafte Mitglieder der Community zu Wort gemeldet und verschiedene Namensschemas vorgeschlagen. Der Trend geht allerdings in Richtung Aufgabe der Namen wie Eclipse Neon, Mars oder Luna, hin zu einer an IntelliJ erinnernden Jahreszahl als Versionsbezeichnung (Eclipse 2017.0, Eclipse 2017.1 und Eclipse 2017.2).

Das größte Problem dabei ist, dass Eclipse ein großes Update im Juni fährt und das Release 2017.2 (als Ersatz für Oxygen.2) erst im Februar 2018 veröffentlicht würde. Dies könnte zu noch größeren Verwirrungen führen als das alte Namensschema. Gunnar Wagenknecht schlug als Lösung dafür vor, die Versionsbezeichnung Neon (4.6) durch Neon (06/2016) zu ersetzen, entsprechend dann Neon.1 (09/2016) und Neon.2 (02/2017).

Aber mal ehrlich, muss das wirklich sein? Aus eigener Erfahrung kann ich sagen, dass es in Sachen Aktualität keine zwei Minuten dauert, um herauszufinden, welches Eclipse nun das aktuellste ist. Als Beispiel könnte man Android anführen, das ebenfalls einer ganz ähnlichen Namensstruktur anhängt: Android Marshmallow ist das aktuelle Android, die direkten Vorgänger waren Lollipop bzw. KitKat.

Während allerdings bei Android die interne Versionierung sehr unübersichtlich ist (wer kennt schon die Unterschiede zwischen Android 4.4.1 und 4.4.2?) ist es bei Eclipse ziemlich eindeutig. Es gibt exakt drei Versionen pro Release, zum Beispiel Neon, Neon.1 und Neon.2. Eine Verwechslung ist nahezu ausgeschlossen, Zwischenversionen gibt es nicht und die Download-Seite ist übersichtlich eingeteilt.

Wenn die Jahreszahl unbedingt gewollt wird, erscheint mir Gunnar Wagenknechts Versionsschema noch am besten, denn so hat die Community weiterhin die Möglichkeit, einen drolligen Namen für das geliebte Produkt zu suchen und eine Verwechslung oder Ratlosigkeit, was die Aktualität angeht, ist ausgeschlossen. Solange es bei Eclipse ein Major-Release gibt und die ehemaligen „Service Releases“ nicht im gleichen Jahr erfolgen, ist eine Versionierung nach Art von 2016.x einfach nicht sinnvoll.

Interview mit Jonas Helming auf der JAX 2016

Mein Kollege Hartmut Schlosser hatte auf dem Eclipse Day der diesjährigen JAX in Mainz die Möglichkeit, Jonas Helming (EclipseSource München GmbH) zu interviewen. Im Gespräch ging es um die aktuellen Geschehnisse in den Bereichen IoT, Modeling und der Entwicklungsumgebung allgemein. Und natürlich durfte die Frage nicht fehlen, wie sich Eclipse im Vergleich zur Konkurrenz NetBeans und IntelliJ schlägt.

Was sind sonst in Sachen Eclipse auf der JAX 2016 ergeben hat, findet Ihr übrigens im Bericht: Eclipse-Standortbestimmung: Wo es steht, wohin es geht.

Great Fixes for Neon II

Wie angekündigt, gibt es in dieser Woche den zweiten Gewinner des Wettbewerbs Great Fixes for Neon zu beglückwünschen. Mit 80 Contributions zum Projekt Eclipse C/C++ Development Tools (CDT) hat sich Nathan Ridge den Platz in der diesjährigen Ehrenhalle redlich verdient.

Bereits seit 2010 ist Ridge dabei, Bugs im CDT-Projekt zu melden. Seit vier Jahren arbeitet er aktiv daran mit, Bugs zu fixen. Die C/C++ Development Tools nutzt er sowohl privat für eigene (Lern-)Projekte als auch im täglichen Berufsleben. Im Januar dieses Jahres wurde Nathan Ridge von Sergey Prigogin offiziell als Committer vorgeschlagen und kurz darauf Teil des Teams.

Herzlichen Glückwunsh, Nathan!

Liebesbedürftig: Eclipse Andmore

Auf seinem Blog hat Doug Schaefer einen Hilfeschrei in Vertretung des Projektes Eclipse Andmore veröffentlicht. Seit Google sich dafür entschieden hat, IntelliJ den Vorzug zu geben und mit dem neuen Android Studio die Eclipse Community in einen von ihm so diagnostizierten Schockzustand versetzte, ist die Entwicklung von Anwendungen für Android in Eclipse ein wenig eingeschlafen.

Quelle: CDT Doug

Quelle: CDT Doug

Das Projekt Andmore wollte zwar explizit die von Google entwickelten ADT-Plug-ins weiterführen und hatte durchaus ambitionierte Ziele, doch die Zahl der Contributors hält sich hartnäckig in Grenzen. Für Doug Schaefer ist es ein wenig frustrierend zu sehen, dass andere Projekte (wie Platform UI) sehr viele Contributors und Committer anziehen, andere Projekte hingegen brach liegen oder es schlicht nicht schaffen, Fahrt aufzunehmen

Um Andmore erfolgreicher und eine vernünftige Programmierung von Android-Applikationen möglich zu machen, ist der Support von Gradle, so Schaefer, unabdingbar. Auch die Rückführung einiger jar-Dateien aus dem Android SDK in die Eclipse Plug-ins sei notwendig, um Andmore wieder konkurrenzfähig zu machen.

Doug Schaefers abschließenden Worten ist wenig hinzuzufügen:

I truly hope that a segment of the Eclipse community will feel that supporting Android development with Eclipse is important. Hell, I think supporting iOS is important too. We can’t be the IDE for everything without having support for the big things.

Das ewige Leid mit den Standards (Internet of Things Edition)

In der großen IoT-Umfrage der Eclipse Foundation war eines der Schlüsselthemen die Interoperabilität. Für knapp ein Drittel der Teilnehmer war diese Frage wichtig, woraus sich schließen lässt, dass sich Entwickler in diesem Umfeld durchaus damit beschäftigen (müssen).

Das große Problem, wie Ian Skerrett in einem Beitrag auf seinem Blog feststellt, sind die vielen Standards, die mittlerweile existieren. Viele dieser Standards sind für ganz unterschiedliche Bedürfnisse erstellt worden. Außerdem gibt es bereits viele Standards, die seit Jahren verwendet werden und sich nicht so einfach ersetzen lassen.

As the saying goes: Standards are like toothbrushes, everyone wants to use one but not other peoples.

–Ian Skerrett

Diese Vielzahl an IoT-Standards wird sich auch zukünftig nicht vermeiden lassen, prognostiziert Skerrett, daher sei eher die Frage, wie die Interoperabilität gewährleistet werden kann. Der beste Ansatz könnte sein, nicht im Bereich der Standards nach einer Lösung zu suchen, sondern innerhalb laufender Software. Diese sollte bestenfalls natürlich dem Open-Source-Gedanken entsprechen. Wie Interoperabilität erreicht werden könnte, hat Kai Kreuzer, Projektleiter von Eclipse SmartHome, in einem Video demonstriert:

Scott Lewis, Projektleiter des Eclipse Communication Frameworks, gab allerdings zu bedenken, dass IoT-Entwickler ständig abwägen müssen, welchen Standard sie verwenden, nur um ihre Anwendung überhaupt zu erstellen. Eine falsche Entscheidung kann leicht sehr kostspielig werden, wenn das gewählte Protokoll nicht so funktioniert, wie vorgesehen.

Er bietet allerdings auch eine Lösung dafür an: ECF Remote Services. Damit können Entwickler ihr Programm oder die Anwendung schreiben, ohne sich auf Kommunikationsprotokolle festzulegen. Stattdessen wird ein Distributionsprovider verwendet (weitere Informationen dazu finden sich hier).

Dies löst zwar nicht die Frage nach den IoT-Standards, erleichtert es für Entwickler aber, ihre Anwendung zu erstellen und erst am Ende die richtigen und wichtigen Protokolle auszuwählen.

Aufmacherbild: The Moon covering the Sun in a partial eclipse. von Shutterstock.com
Urheberrecht: solarseven

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

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: