Neues aus dem Land der Sonnenfinsternis

Eclipse Weekly: Eclipse Che 6.0, EE.Next Working Group & RedOx wird Corrosion

Dominik Mohilo

© Shutterstock.com / solarseven

Nachdem Red Hat Codenvy übernommen hatte, bekam man den Eindruck, es würde ein wenig ruhig um Eclipse Che. Doch weit gefehlt: Man arbeitete unter Hochdruck am neuen Major Release, welches nun in Form von Che 6 erschienen ist – und tonnenweise neue Features an Bord hat. Außerdem werfen wir in dieser Woche einen kurzen Blick auf die EE.Next Working Group, die sich um die Zukunft von Java EE kümmern wird und schauen uns an, warum Eclipse RedOx nun Eclipse Corrosion heißt.

Eclipse Che 6.0: Multi-User-Modus & neues UI

Die Cloud IDE Eclipse Che hat mit Version 6 den nächsten großen Meilenstein erreicht. Über 1550 Commits wurden laut eigener Aussage für Che 6 durchgeführt, das Release ist also ziemlich umfangreich. Besonders hervorzuheben ist dabei der neue Multi-User-Modus, durch den mehrere Nutzer auf einem Che-Server arbeiten können. Außerdem setzt man beim User-Management nun auf Keycloak und es gibt ein neues User Interface.

Alles fürs Team

Wie bereits erwähnt ist Eclipse Che nun in zwei verschiedenen Modi nutzbar. Einmal klassisch im Single-User-Modus für den persönlichen Gebrauch auf dem Desktop. Ab Che 6 ist aber auch ein Multi-User-Modus verfügbar, der Mandantenfähigkeit und Zugriffskontrolle (basierend auf Keycloak) an Bord hat. Für den Log-in werden Standardprotokolle wie OpenID Connect, OAuth 2.0 und SAML 2.0 unterstützt, alternativ kann man sich auch über GitHub, Twitter oder Google einloggen.

Log-in-Fenster in Eclipse Che / Quelle: Che Blog

Laut den Machern von Eclipse Che ist es damit möglich, auf einem einzigen Che-Server Hunderte Workspaces zu orchestrieren. Der Single-User-Modus bleibt allerdings, das sei noch erwähnt, der Standardmodus beim Start von Eclipse Che. Das liegt daran, dass für den Multi-User-Modus eine Authentifizierung nötig ist und man die Nutzer nicht mit unnötigen Passwortabfragen nerven möchte, wenn sie Che nur persönlich nutzen wollen.

Oft kommt es vor, dass ganze Teams kollaborativ an Projekten arbeiten, was natürlich die Notwendigkeit der Organisation und des Ressourcenmanagements mit sich bringt. Che 6 bringt hierfür neue Tools für Administratoren, sodass sie Entwickler gruppieren und die geteilten Ressourcen verwalten können.

Vordefiniert sind hierbei drei Rollen: System Admins, Admins und Members. Allerdings können auch ganz individuell und feingranuliert die Rechte verteilt und neue Rollen definiert werden. Es können in Che auch sogenannte Organizations angelegt werden, die wiederum Suborganizations haben, und aus den verschiedensten Mitgliedern bestehen. Individuell kann auch die Ressourcen festgelegt werden.

Ressourcenverwaltung in Che / Quelle: Che Blog

Durch das Permissions API können die oben genannten feingranulierten Rechte angepasst werden. Dabei setzt Che 6 nicht auf vordefinierte Rechte, stattdessen können die Rechte von Workspaces, Organizations, Stacks, Recipes und Systems unterschiedlich und individuell angepasst werden. Nutzer, die bspw. auf einen bestimmten Workspace eingeladen werden, können folgenden Rechten ausgestattet werden:

  • Read: User kann Workspace-Konfigurationen einsehen
  • Use: User kann den Workspace nutzen und damit interagieren
  • Run: User kann den Workspace starten und stoppen
  • Configure: User kann die Konfiguration des Workspaces definieren und ändern
  • SetPermissions: User kann die Zugriffsrechte für andere User des Workspaces bearbeiten
  • Delete: User kann den Workspace löschen

Das neue User Interface

Da viele Entwickler lieber mit ihren Händen auf dem Keyboard bleiben und nicht zur Maus greifen wollen, während sie in die Arbeit vertieft sind, war eines der Ziele für das neue UI von Che, neue Shortcuts zu etablieren. Minimalismus, das heißt die Entfernung ablenkender Elemente, war eine der Grundvoraussetzungen für das neue Design, ebenso wie eine möglichst große Arbeitsfläche, in der am Code direkt gearbeitet wird.

UI mit vielen Helfern für die Arbeit am Code / Quelle: Che Blog

Im neuen UI kann man sich nun entscheiden, ob man sich den Project Explorer, das Terminal, den Editor und weitere Helfer anzeigen lässt (siehe Bild oben), oder sich mit dem Code-Editor begnügen möchte (siehe Bild unten). Statt des dunklen Themes gibt es übrigens auch ein Light Theme mit weißem Hintergrund.

UI für ablenkungsfreies Coden / Quelle: Che Blog

Sonstiges

Wenig verwunderlich ist, dass Che 6 die Unterstützung für OpenShift beinhaltet. Das Unternehmen Codenvy, das Eclipse Che entwickelt, ist schließlich vor einiger Zeit von Red Hat aufgekauft worden. OpenShift wird nun also (neben Docker) nativ supportet. Eclipse Che kann zum Beispiel auf die OpenShift Container Platform (OCP), OpenShift Online (OSO), OpenShift Dedicated (OCD) und MiniShift (OpenShift auf dem lokalen Host) deployt werden.

Um das möglich zu machen, wurde die Infrastruktur von Eclipse Che 6.0 umgeschrieben und eine neue Abstraktionsebene integriert. Diese soll es leichter machen, die Unterstützung für andere Workspace Orchestrierungsengines zu ermöglichen. Che kommuniziert nun nicht mehr direkt mit der Infrastruktur. Stattdessen verlässt sich Che 6 ab sofort darauf, dass die Service Provider Infrastructure (SPI) der Infrastruktur die nötigen Informationen für die Orchestrierung und Provisionierung der Workspaces zur Verfügung stellt.

Für alle Kubernetes-Fans: Dank der neuen SPI wird auch Kubernetes bald nativ von Eclipse Che unterstützt werden (als weitere Alternative zu Docker und OpenShift).

Last but not least wurde der Debugger für Che 6 überarbeitet und man kann nun bspw. sämtliche Threads des Codes einsehen. Bestimmte Konditionen, wann ein Breakpoint erreicht ist, und Regeln für das Aussetzen des Debuggings können ebenfalls definiert werden. Wer bestimmte Ausdrücke während des Debugging-Prozesses im Auge behalten will, kann eine Watch List erstellen.

Breakpoints und Aussetzen des Debuggings konfigurieren / Quelle: Che Blog

Weitere Informationen zur neuen Major Version von Eclipse Che gibt es in den offiziellen Release Notes.

Java EE, EE4J & EE.Next – das ist los

In Sachen Namensgebung

Es wird verwirrend, daher aufgemerkt und aufgepasst. Sprechen wir derzeit über die Zukunft von Java EE und des Java Community Process (JCP) schwirren verschiedenste Bezeichnungen im Raum herum, daher zunächst ein kurzer Disclaimer: Der neue Markenname von Java EE ist noch nicht existent. EE4J ist (bislang) lediglich der Name des Top-Level-Projektes bei der Eclipse Foundation, Fakt ist allerdings, dass Java EE als Marken- oder Brandname nicht mehr lange verwendet werden wird.

Der nächste Platzhalter wurde nun mit Gründung der EE.Next Working Group bei der Eclipse Foundation geschaffen. EE.Next ist hierbei der Platzhalter für den neuen Namen von Java EE. Laut der offiziellen EE4J-Mailing-Liste soll die Community-Abstimmung über den neuen Namen allerdings noch in diesem Monat endlich starten, der Abstimmungszeitraum dürfte etwa vier Wochen betragen.

EE.Next Working Group

Die frisch gegründete EE.Next Working Group ist nun der erste Schritt in Richtung eines neuen Java Community Process (JCP), wie ihn einige vielleicht schon von Oracle (oder sogar noch von Sun Microsystems) kennen. Das „neue Java EE“, welchen Namen es auch immer tragen wird, wird dann komplett vom bisherigen JCP losgelöst sein und die Weiterentwicklung dem neuen Prozess und damit den Mitgliedern der EE.Next Working Group obliegen.

Der Unterschied zum bisherigen Verfahren ist, dass keiner (auch nicht Oracle oder die Eclipse Foundation) einen Sonderstatus oder spezielle Rechte innerhalb des neuen Prozesses innehaben wird. Zudem soll der Prozess weniger sperrig, sondern agil und modern sein – angepasst an die Schnelligkeit, mit der Java-Technologien heutzutage entwickelt werden.

Strategic Member Influencer Member Participant Member Committer Member
Member of the Steering Committee Appointed Elected Elected Elected
Member of the Specification Committee Appointed Elected Elected Elected
Member of the Marketing Committee Appointed Elected Elected Elected
Member of the Enterprise Requirements Committee Appointed Appointed N/A N/A

Organisatorisch wird die Working Group in vier Komitees eingeteilt sein, die die unterschiedlichen Aspekte und Aufgaben für die Weiterentwicklung von Java EE abdecken. Diese Komitees setzen sich aus Mitgliedern zusammen, die gewählt oder auf andere Weise bestimmt werden. Die Tabelle oben zeigt, wie in etwa das Modell aussehen wird.

Die Mitgliedschaft in dieser illustren Gruppe ist für Organisationen und Einzelpersonen offen, wobei die Mitgliedschaft von Organisationen in drei Abstufungen (Strategic Members, Influencer Members und Participant Members) möglich ist, die sich nach dem Mitglied-Status bei der Eclipse Foundation selbst richten. Einzelpersonen müssen als Committer akzeptiert worden sein und den Anforderungen eines noch zu definierenden Participation Agreements zustimmen.

Weitere Informationen zur neuen EE.Next Working Group gibt es hier auf JAXenter und auf dem Blog von Mike Milinkovich. Die Charta der Working Group enthält sämtliche Details zur Organisation und den Aufgaben der Working Group selbst und den unterschiedlichen Komitees darin.

Eclipse RedOx = Eclipse Corrosion

Ein altes Sprichwort besagt: Wer rastet, der rostet. Im Zusammenhang mit der Programmiersprache Rust hat dieser Spruch bereits einen solch langen Bart, dass selbst der Alm-Öhi vor Neid erblassen würde. In Bezug auf das neue Projekt Eclipse RedOx, hinter dem sich eine neue IDE für Rust versteckt, passt der Spruch allerdings ganz hervorragend. Was? Das Projekt gibt es gar nicht? Richtig! Da man keinen Rost ansetzen will, wurde er geändert.

Lesen Sie auch: Rust 1.23 & Eclipse RedOx – die Eclipse IDE für Rust

Naja, fast jedenfalls. Der eigentliche Grund für die Namensänderung des Projektes ist die Tatsache, dass das Rust-Projekt Redox OS bereits existiert. Redox OS ist ein in Rust geschriebenes, Linux-artiges Betriebssystem. Da man sich mit der neuen Rust-IDE nicht in die Nesseln setzen möchte, hat man kurzerhand beschlossen, das Projekt in Eclipse Corrosion umzubenennen. Treffender könnte der Name kaum ausfallen.

So ganz neu ist die Idee, ein Rust-Projekte „Corrosion“ zu nennen, allerdings auch nicht. So existiert etwa ein NES-Emulator (NES = Nintendo Entertainment System), der als Hobby-Projekt in Rust geschrieben wurde und den gleichen Namen trägt (siehe GitHub). Ins Gehege wird man sich an der Stelle allerdings wohl nicht kommen.

Weitere Informationen zu Eclipse Corrosion (ehemals RedOx) gibt es hier auf JAXenter, im offiziellen Proposal bei der Eclipse Foundation und natürlich auf GitHub.

@EclipseJavaIDE: Tipp der Woche

Der Eclipse-Tipp der Woche wird in Zusammenarbeit mit Sopot Cela präsentiert, der unter dem Handle @EclipseJavaIDE Tag für Tag wertvolle Tipps und Tricks für die Nutzer der Eclipe IDE veröffentlicht.

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

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: