© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Lagebericht Eclipse-IDE

Kolumne: Lagebericht Eclipse-IDE


Bei Veröffentlichung dieser Zeilen genießt ihr hoffentlich gerade die Neuerungen von Eclipse 4.7. Unterdessen ist das Plattformteam natürlich schon dabei, an den kommenden Versionen 4.7.1 und 4.8 zu arbeiten. Diesmal geht es im Lagebericht um einen Ausblick auf das, was für das nächste Release geplant ist. Ob diese Änderungen dann aber tatsächlich umgesetzt werden, hängt natürlich unter anderem von euren Beiträgen ab. Den Unterschied zu einem Projekt, das von einem einzigen Unternehmen geführt wird, sieht man aber nicht nur daran. Auch organisatorisch ist das Eclipse-Ökosystem nicht statisch, sondern einem steten Wandel unterworfen.

So hat Thomas Watson von IBM vor Kurzem vorgeschlagen, Equinox und p2 wieder zurück zur Plattform zu bringen [1]. Equinox wurde in der Vergangenheit aus dem Platform-Projekt herausgelöst und dem Top-Level-Projekt Runtime zugeführt. Leider gibt es nur wenige Entwickler, die sich aktiv um Equinox kümmern, und für p2 leider noch weniger. Von daher wird das Equinox-Projekt, sofern es keinen Widerspruch gibt, wieder mit dem Plattformprojekt zusammengeführt. Durch diesen Schritt kann dann auch das Führungsteam helfen, neue Entwickler für die Projekte Equinox und p2 zu begeistern. Versuche, neue Committer zu p2 zu bringen, wurden ja leider in der Vergangenheit blockiert [2].

Das Google-Team hat sich sehr zu meinem Bedauern vom Eclipse-Projekt offiziell verabschiedet. Über interne Prozesse gibt Google freilich offiziell keine Auskunft, Gerüchten zufolge haben sie aber ein internes, textbasiertes Refactoring-Tool entwickelt. Dieses soll dabei behilflich sein, Änderungen an der großen Codemasse bei Google durchzuführen.

Zurzeit wird im Plattformteam ebenfalls diskutiert, ob man nicht auch die Subprojekte zusammenlegen sollte. Die Projekte SWT, Platform UI usw. wären dann ein einziges großes Projekt. Eventuell könnte man dann sogar das Plug-in Development Environment und die Java Development Tools integrieren. Den existierenden Committern würde es auf diese Weise viel leichter fallen, in einer fremden Codebasis auf die Schnelle kleinere Änderungen durchzuführen. Neue Contributors könnten sich zudem viel schneller eine Historie von Codebeträgen aufbauen, die ihnen dann auch den Committer-Status ermöglichen würde. Prinzipiell wäre das Zusammenführen der Projekte definitiv eine sinnvolle Vereinfachung des Projekts. Ich hoffe jedenfalls sehr, dass es klappen wird.

Aufräumen für Eclipse 4.8: Erst die Arbeit...

Den Beginn eines neuen Releases ...

Java Magazin
Kolumne: Lagebericht Eclipse-IDE

Kolumne: Lagebericht Eclipse-IDE

Bei Veröffentlichung dieser Zeilen genießt ihr hoffentlich gerade die Neuerungen von Eclipse 4.7. Unterdessen ist das Plattformteam natürlich schon dabei, an den kommenden Versionen 4.7.1 und 4.8 zu arbeiten. Diesmal geht es im Lagebericht um einen Ausblick auf das, was für das nächste Release geplant ist. Ob diese Änderungen dann aber tatsächlich umgesetzt werden, hängt natürlich unter anderem von euren Beiträgen ab. Den Unterschied zu einem Projekt, das von einem einzigen Unternehmen geführt wird, sieht man aber nicht nur daran. Auch organisatorisch ist das Eclipse-Ökosystem nicht statisch, sondern einem steten Wandel unterworfen.

Lars Vogel


Bei Veröffentlichung dieser Zeilen genießt ihr hoffentlich gerade die Neuerungen von Eclipse 4.7. Unterdessen ist das Plattformteam natürlich schon dabei, an den kommenden Versionen 4.7.1 und 4.8 zu arbeiten. Diesmal geht es im Lagebericht um einen Ausblick auf das, was für das nächste Release geplant ist. Ob diese Änderungen dann aber tatsächlich umgesetzt werden, hängt natürlich unter anderem von euren Beiträgen ab. Den Unterschied zu einem Projekt, das von einem einzigen Unternehmen geführt wird, sieht man aber nicht nur daran. Auch organisatorisch ist das Eclipse-Ökosystem nicht statisch, sondern einem steten Wandel unterworfen.

So hat Thomas Watson von IBM vor Kurzem vorgeschlagen, Equinox und p2 wieder zurück zur Plattform zu bringen [1]. Equinox wurde in der Vergangenheit aus dem Platform-Projekt herausgelöst und dem Top-Level-Projekt Runtime zugeführt. Leider gibt es nur wenige Entwickler, die sich aktiv um Equinox kümmern, und für p2 leider noch weniger. Von daher wird das Equinox-Projekt, sofern es keinen Widerspruch gibt, wieder mit dem Plattformprojekt zusammengeführt. Durch diesen Schritt kann dann auch das Führungsteam helfen, neue Entwickler für die Projekte Equinox und p2 zu begeistern. Versuche, neue Committer zu p2 zu bringen, wurden ja leider in der Vergangenheit blockiert [2].

Das Google-Team hat sich sehr zu meinem Bedauern vom Eclipse-Projekt offiziell verabschiedet. Über interne Prozesse gibt Google freilich offiziell keine Auskunft, Gerüchten zufolge haben sie aber ein internes, textbasiertes Refactoring-Tool entwickelt. Dieses soll dabei behilflich sein, Änderungen an der großen Codemasse bei Google durchzuführen.

Zurzeit wird im Plattformteam ebenfalls diskutiert, ob man nicht auch die Subprojekte zusammenlegen sollte. Die Projekte SWT, Platform UI usw. wären dann ein einziges großes Projekt. Eventuell könnte man dann sogar das Plug-in Development Environment und die Java Development Tools integrieren. Den existierenden Committern würde es auf diese Weise viel leichter fallen, in einer fremden Codebasis auf die Schnelle kleinere Änderungen durchzuführen. Neue Contributors könnten sich zudem viel schneller eine Historie von Codebeträgen aufbauen, die ihnen dann auch den Committer-Status ermöglichen würde. Prinzipiell wäre das Zusammenführen der Projekte definitiv eine sinnvolle Vereinfachung des Projekts. Ich hoffe jedenfalls sehr, dass es klappen wird.

Aufräumen für Eclipse 4.8: Erst die Arbeit...

Den Beginn eines neuen Releases ...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang