Roadmap 2017

This roadmap is a 6-9 month forward-looking expectation of what we plan to include in Eclipse Che.

This roadmap is thematically tied to three audiences:

1. Users (developers)
2. Ecosystem (ISVs)
3. Admins (enterprises / teams)
4. Che-Dev (development community)

Releases occur every three weeks. While working on a current release, we plan the following release. We thematically break the major functionality into epics that have sub-issues that can span many sprints, and sometimes across many releases. We do our best to incorporate all of feature into a single release, but it often requires that we break functionality across multiple release milestones.

The epics and features that roll into a milestone are determined by pull request readiness of the feature at the time a milestone begins. In other words, we only place into a milestone features that are code complete and waiting for master-integration and testing.

Che 6

Eclipse Che should provide a developer experience that rivals world-class tools such as the Eclipse IDE and JetBrains. Workspaces should be configurable to work with any kind of language and have best-in-class support for the language server protocol along with packaging all known language servers. Users must be able to perform any action using a unified command palette. VCS experience should be simpler and better integrated in the IDE. Navigating into source code, searching and performing actions accross multiple files should also become more natural and designed for efficiency. These needs will also involve an important work on the UI and the UX for the IDE.

An extensibility model must also be introduced for Eclipse Che. Contributor should be able to author extensions with the technologies of their choices. Extensions must have their own lifecycle to be released independently from Eclipse Che core. Turnaround developing Che extension must be smoother and faster. Extension points must be introduced. Creating Che extension must be best in Che. Users must be able to select extensions per workspace. An extension marketplace should be introduced.

Eclipse Che must not rely on specific and custom stacks to provide tooling. Tooling must run as companion sidecars of the workspace machines.

Che 6 GA

Professional Development Tool

• Reliable Java tooling for class deletion/renaming/moving #5013, #4979, #3928
• Typescript Support (code completion, errors and syntax highlighting, formatting, refactoring and code navigation) #5146
• Improved unit tests support #4994, #4980
• Debugger with thread support, conditional breakpoints #2611

Redesigned User Experience

• New IDE design and experience #4929, #4993, #7577
• UD re-design for ws create + details + crane along with reducing output of agent boot #4359
• New workspace loading sequence #5128

Infrastructure and Foundations

• Workspace Infrastructure (SPI) to support Docker and Openshift #4736
• SPI implementation for Openshift #5098
• (best effort) GWT Super dev mode support #2595, #6602

Che 6 - Post GA Iterations

Extensibility Mecanism

• IDE Javascript extension points #6642
• Self Hosting in Che #6713
• GWT Improvement #7352, #7122

Architecture Improvements

• Easy delivery of Languages Servers #6792, #7554
• Faster workspace loading #6261
• Consolidation of Chefiles and Factories #4362
• Switch Java infrastructure to JDT LS #6157

Infrastructure Support

• Kubernetes Support #1193, #5908, #7589

Professional Development Tool

• Replacement of Orion editor by Monaco #5330
• Generic Testing Support #5978
• Git Dedicated Panel #5128

Other Cool Features

• Guided flows and Tutorial in Che#6150
• Spike on Teletype #438

August 2017 Update: Multi-User, Multi-Tenant Che

We have witnessed a strong need from downstream projects to have a multi-user, multi-tenant Che:

1. codenvy.io, in its push to replace Swarm infrastructure
2. Red Hat OpenShift.io, a devops solution based upon OpenShift
3. SAP Hana, in their investigation for upgrading from Che 3

The Che 6 plan has these features included along with a broader ambition to redesign the IDE, introduce an infrastructure SPI, and include a number of new developer features within the IDE itself.

We are investigating an intermediate release on the Che 5 branch that introduces a multi-user, multi-tenant version of Che on OpenShift.

The 5.x release will:

1. Include the OpenShift adapter built by Red Hat.
2. Certified for Docker and OpenShift, but not yet Kubernetes.
3. Replace Codenvy's authentication with Keycloak.
4. Move the elements for teams, groups, and permissions from Codenvy into Che (including UD).
5. Support multi-tenancy of the Che server on OpenShift.

Most of this engineering work is well scoped and will likely be done within the next 1-2 sprints. However, our engineering teams are making a number of assumptions about how authentication and authorization should work with Keycloak and we need to validate these assumptions in the real world. We will hold on a formal release until we have verification that codenvy.io and OpenShift.io downstream projects have successfully deployed this new solution at scale.

April 2017 Update (Covering April - October)

Users: Create a Professional Development Tool

Eclipse Che should provide a development experience that rivals world-class tools such as the Eclipse IDE and JetBrains. Che should install anywhere. Workspaces should be configurable to work with any kind of language and have best-in-class support for the language server protocol along with packaging all known language servers. Workspaces should be support Docker Compose and enable multi-machine development. There should be an intelligent commands framework that simplifies authoring commands and executing them on different machine targets.

• Performance of IDE as seen by the user #3792, #4250
• Critical issues as documented by dev
• LSP advancements - phase II + file extensions #2109
• Debugger, debugger, debugger #2611
• JavaScript IDE client prototype
• Improve Git commit window #3614

Enterprises: Cloud Dev for Teams on a Single Project

When enterprises adopt Eclipse Che (or the Codenvy derivative), they break themselves into teams that work on projects collectively, but in workspaces that are private and independent. Enterprises are looking to secure workspaces, deploy them on new infrastructure, and make it easier for teams to collaborate on projects together while maintaining developer autonomy. Some of these issues are Codenvy or Red Hat OpenShift issues, but generate significant improvements to the underlying Che platform.

• System stack + template + factory + recipes mgmt #1902, #
• Traffic through a single port #4361
• Consolidate chefiles + factory JSON #4362
• Factory and PR panel in che #4290
• Che and Codenvy infrastructure deploy on Kube / OpenShift #2847, #5052
• Simplified IDE UI
• Improvements for terminals #4824
• UD re-design for ws create + details + crane along with reducing output of agent boot #4359

Ecosystem: Make It Easy to Contribute to Che

Eclipse Che should be easy to customize. Che has many customization points including stacks, templates, extensions, plugins, assemblies, and commands. Currently, these customization and extension points are located and customized in differnet ways. We are going to centralize and standardize these items to make a consistent model for how customizers can work with Che. Additionally, we will advance the infrastructure of Che and our DevOps infrastructure to make it possible to duplicate Che development environments for those that want to give back to the project.

• Archetype SDK (lifecycle of custom assemblies) #4257 & archetype
• QE automation framework [TBD]
• Custom images for each branch with auto-generation from CI [TBD]
• Agent & Machine refactoring #3971 & #3612
• Improved Eclipse Che extensions development flow #4370
• Che-in-Che development model with ability to source workspace recipe from git repo
• Various internal refactoring #3244, #3248, #4221
• Rework agents installation #3971
• Use a single port to route all traffic #4361
• Replace everrest based Websocket calls with new RPC framework. #4459

September 2016

Users: Create a Professional Development Tool

Eclipse Che should install anywhere and be easy to install. It should also be possible for you to get a project-typed workspace with a custom set of commands in a natural, minimal sequence. Eclipse Che should become context-aware and auto-generate workspaces with type and code information based upon the contents of directory or repository.

• Make docker the default execution for Che. #1683
• Add support for the Codenvy / Red Hat / Microsoft language server protocol #1287
• "Code in Che" from any git repository #1895
• Second phase of "Code in Che" from any git repository #2266
• Simplify dashboard navigation to eliminate unnecessary clicks #1743
• Move dashboard navigation to list layout #1762
• Move workspace editing to form layout #1767
• Support /namespace/workspace URL access #1572
• Split view for editor #1837
• Make it possible to add / remove servers without customizing a Dockerfile
• Provide image project type to simplify edit, build, debug of images
• Ability to preview HTML files #1883
• Add intelligent commands - executing against a context #2681

Customizers: Make Customizations More Approachable

Eclipse Che should be easy to customize. Che has many customization points including stacks, templates, extensions, plugins, assemblies, and commands. Where possible, we should make these customizations happen within Che's dashboard or as a project type within the IDE. For assembly-related items, such as custom stacks, Che should be self-updating and dynamic for the addition and removal of items. For extension-related items, such as the IDE, Che should have a simple way to get started developing plug-ins with incremental builds and, if necessary, super dev modes. The project must also evolve its interfaces to support community projects to create value-added layers within Che such as ecore, EMF, GMF, and multi-cursor editing.

• Add, edit, and delete templates and stacks from the dashboard epic:2205
• Localhost machines, to create workspaces without Docker on the host
• Simpler Che-in-Che scenarios epic:2116
• Provide docker images for building Che to reduce configuration See wiki
• Dynamic file watchers with events to auto-update IDEs when workspace files are edited out of band #1824
• JPA data access implementation to store information with in-memory databases #1790
• Make it easier for third party tools to integrate Che #1894
• Refactor che-server and che-launcher containers to use single volume mount for data bindings #2786
• Add initial support for Chedir, reproducible dev environments #1895
• Add support for Chefile interoperability with Factories, and automatic configuration of SSH keys #2266

Enterprises: Expand Che Execution Scenarios

Che needs to run in a variety of environments and support large-scale workspace consumption in an elastic way. There needs to be a clear, prescriptive set of controls for admins who adminster Che systems. We will enable multi-node elasticity in Che, and we will defer multi-user, multi-tenant, and organizational implementations to commercial vendors building more advanced versions of Che.

• Allow off-the-shelf docker images to work within Che #1823
• Dynamic injection of workspace agents #1823
• Start a new workspace with a Docker compose definition - part of 5.0.0-M1 release
• Switch between different runtime environments in a single workspace
• Environment SPI, to allow platform providers like OpenShift to create plugins to manage workspace runtimes #1829
• Che with a reverse proxy to minimize port exposure (workspace URLs will be embedded) #1560
• Migrate Docker images from Codenvy into the eclipse/ DockerHub organization#2737
• Create Che machine exec concept to solve issues with Docker exec #1944