The Eclipse Foundation recently announced the formation of an IDE working group. By providing governance, guiding, and — perhaps most important — funding, the structure is meant to “ensure the continued evolution, adoption, and sustainability of the Eclipse IDE suite of products, related technologies, and ecosystem”.
While this sounds pretty similar to the aim of the Eclipse Foundation itself, the working group also plans to oversee the development of the IDE suite’s release plan, and set the criteria by which final products can be called official. Other work items include the provision of a “framework under which the production of all intermediate products required in the creation of the Eclipse IDE downloads is carried out”, and assistance in growing the IDE’s ecosystem.
The group includes a steering committee which defines and tracks a common working strategy as well as a planning council. The latter is made up of “senior technical experts” who are responsible for “managing the Eclipse IDE Simultaneous Release, cross-project planning, facilitating the mitigation of architectural issues and user interface conflicts, and all other coordination and integration issues”.
Founding organisations of the working group include companies like Bosch, IBM, SAP, and VMware. To participate in the group, candidates must at least be a Contributing Member of the Eclipse Foundation, execute the Eclipse IDE Working Group Participation Agreement, and pay a participation fee, details of which are available in the group’s charter.
The news of the additional governing body got in shortly after the Eclipse Foundation put its 2021-06 release train into developers’ hands. Among the updated projects was the Eclipse SDK, whose version 4.20 includes noteworthy changes such as support for Java 16, enhancements for the local variable creation quick fix, various new clean-ups and optimisations in the Java editor.
Eclipse’s Git integration EGit now shows more information about conflicts in its staging view, while the merge editor sports an option to hide changes between the current commit and an ancestor during the merge preparation of two commits or when cherry-picking changes. It also comes with an option to get a pre-merged file with all conflicts resolved to your current version but no conflict markers, and an API to give third-party bundles access to git information, if necessary.