Eclipse Che 7

Gerben Oolbekkink (gjwoolbekkink), Ana Šemrov (asemrov), Yorick de Vries (yorickdevries), Rukai Yin (ryin)

Eclipse Che is a next-generation, cloud-based IDE that can also serve as a developer workspace server for individuals, small teams, and enterprises. Though it is mainly deployed as a SaaS, it can also be installed to local hosts or shared servers. Eclipse Che 7: New & Noteworthy Florent Benoit. 2 Introduction to Eclipse Che 7 Eclipse Che. 3 Development time spent on configuration and setup Activities that require configuration and setup: - Onboarding on a new project - Switching between different projects, technologies. Since the Eclipse Che team just released both 6.19.3 and 7.0.0-beta-3.0 versions 7, we consider both Che 6 and 7 and discuss what the new Che 7 brings to the developers. Stakeholders We have identified stakeholders of Che by analyzing the Che repository 8, Github’s Insights and the official Eclipse Che website. Che 7 comes with a pre-packaged, web-based IDE based on an extended version of Eclipse Theia to provide 'an in-browser Visual Studio Code experience,' the Foundation said in a statement, adding, 'Eclipse Che and Eclipse Theia are already integral to cloud native solutions from vendors such as Google, IBM and Broadcom, among others.

Introduction

Eclipse Che is an open-source workspace server and an integrated cloud-based browser IDE, with the aim to offer a flexible, extensible, distributable and zero-install software development environment.

To put the project in a historical context, the eXo Platform first started with the idea of a cloud-based IDE in 2009 1. After three years of development and a substantial increase in popularity of the software, an investment was obtained to build a highly customizable commercial cloud development product and Codenvy was founded as a standalone business 1.

Eclipse che 7

In 2014 Codenvy donated the intellectual rights to the Che kernel to Eclipse Foundation2 and Eclipse Che (named after Cherkasy, Ukraine, where most of the development takes place) was announced as one of the top-level projects of Eclipse Cloud Development3. Codenvy then became a strategic member of the Eclipse Foundation, taking a board seat4. Nowadays Codenvy still bases its flagship product on Eclipse Che and was acquired by Red Hat in 20175, making Red Hat the biggest contributor to the project.

The Eclipse Che team believes in the future of cloud development. “Cloud development has the potential to turn organizations into lean, continuous operations and enable teams to release more frequently and ship faster”, said Tyler Jewell, the Che project leader and former CEO of Codenvy4. The project thus aims to provide a cloud development solution with all the technologies, platforms, and protocols necessary in order to ease the path to global adoption of cloud development.

Developing in the cloud relies on development environments that can be built and set up easily, with one-click, greatly simplifying team onboarding and collaboration. Indeed, the vision the Che team has held for years is to allow anyone to contribute to a software project without the need of installing additional software6. Compatible with multiple container orchestration systems, Che supports both single-user as well as multi-user development, which makes it more adaptable and supportive for teams. Furthermore, integrated within Red Hat’s OpenShift.io platform, Che enables developers to run it as SaaS.

In addition, Eclipse Che is designed to be a platform where developers can also build and integrate their own development tools. By writing and adopting extensions, it is up to the vision and creativity of Che’s users to create new solutions. This way, Che offers a similar to its desktop Eclipse counterpart - developers are given an extensible development environment, but accessible through the cloud4.

In this report we analyze and provide a high-level understanding of the architecture of the Eclipse Che project. We first identify the key stakeholders of the project and describe the context of Che. We then analyze the technical debt and offer more insights from two viewpoints: a development view and a functional view. Since the Eclipse Che team just released both 6.19.3 and 7.0.0-beta-3.0 versions7, we consider both Che 6 and 7 and discuss what the new Che 7 brings to the developers.

Stakeholders

We have identified stakeholders of Che by analyzing the Che repository8, Github’s Insights and the official Eclipse Che website. We will formulate this list mainly following the scheme defined by Rozanski and Woods in the book Software Systems and Architecture9,10.

Acquirers

Codenvy donated the Che kernel to Eclipse Foundation and has since been acquired by Red Hat, all while still continuing to build its commercial product on top of Eclipse Che. We thus consider Eclipse Foundation and especially Red Hat as the acquirers of Che.

Assessors

The project has two Eclipse Foundation assigned mentors - Mik Kersten and Marcel Bruch, who is also a member of the Eclipse Foundation Architecture council.They are the assessors of Che, as their main concerns are Che’s continued technological success and innovation, widespread adoption, and future growth 8.

Communicators

Everyone with a role in Che’s Development Process8 - including contributors, committers, reviewers, triagers, maintainers and project leaders - is expected to be a communicator of Che, since they understand the details of the architecture and can explain them, for example, to technical authors responsible for the documentation.

Developers

All the contributors and committers to the project on GitHub are developers of Che. Most of the contributions come from Codenvy / Red Hat employees since Codenvy built the kernel of Che and the two organisations remain the major stakeholders of the project.

We list the top-five contributors by the number of commits (as of April 2019):

Maintainers

The Che development team lists all the project maintainers8, assigning them to different product areas including IDE, language servers, platform, dashboard, QA automation, and others.

The maintainers are responsible for managing the issue backlog, ensuring code quality and guiding technical decisions8. Maintainers also periodically review pull requests (PRs) related to their respective product area - this is to make sure the PR reviewer lists are correct as well as to oversee the quality of the reviews themselves.

Integrators

The integrator tasks are mostly done by the maintainers and codeowners. PR merges require the approval of at least one of the maintainers811. PRs that include documentation and release notes updates must also include a project manager (PM) reviewer. In addition, Tyler Jewell, one of the project leaders, can authorize the merging for any PR. The integrators take care that the reviewers focus on code style, readability of the code and usability for other developers.

Contributors with commit rights will merge their own PRs after all reviews are done, while those without commit rights will have the maintainer merge the PR instead. In addition, maintainers are responsible for periodically reviewing the open PRs8.

Suppliers

Che is implemented mostly by Java and runs on top of Apache Tomcat by default. Part of the project is developed using TypeScript. It is built upon Docker 1.8+ and Maven 3.3.1+. The IDE used inside the browser used to be written using GWT until Che 6 and has been using Theia since Che 7.

The Che project uses GitHub for code version control, issue tracking and releases, and Jenkins CI server hosted by Codenvy for continuous integration.

Support Staff

Anyone can ask for support and request features using GitHub issues. Weekly community meetings12, a public Mattermost channel and a developer mailing list are all open for everyone to join and ask for help. Dave Neary, a Red Hat open source community manager, also acts as a community manager for Eclipse Che.

System Administrators

In a company or organization, Che may be deployed by IT specialists in which case the IT department takes on the system administrator role. System administrators are concerned with Che’s deployment, updates, plugin installations, and should be the first point of contact for users if anything goes wrong with Che.

Individual users who download, deploy and develop projects with Che are considered system administrators themselves. When Che is used as SaaS hosted at che.openshift.io, OpenShift assumes the role of system administrator instead.

Testers

All contributors are supposed to be testers and are responsible for the code they submit. The Che development team requires all contributors to follow the Development Workflow11 for the purpose of submitting high-quality code.

Users

We identified three classes of Che users.

Application developers are the primary users of Che. They can use it either with via the embedded browser IDE or instead with a different desktop IDE by mounting the Che workspace filesystem via SSH.

Product owners use Che by managing settings on the workspace server to provide on-demand workspaces for developer teams.

Extension providers make use of the Che SDK to extend and provide new customizations for Che.

Competitors

There are several competitors to Che on the market, some of them open sourced and some not. Here we mention three main competitors:

  • Cloud9 IDE is another online integrated development environment and supports multiple programming languages developed by Amazon. It is written almost entirely in Javascript and published as open source from version 2.0.
  • Azure DevOps, formerly called VisualStudio Online before it was rebranded as Visual Studio Team Services (VSTS), is an online platform that supports Team Foundation Server and rolling release models.
  • Codeanywhere is another cross-platform cloud IDE created by Codeanywhere, Inc. It is written entirely in Javascript.

People to Contact

Eclipse

We sent an email to the mailing list and showed our interest in talking with some developers. Dave Neary, the community manager, replied and invited us to attend the Che weekly meeting on April 1st, 2019 in which three developers Thomas Maeder, Stevan LeMeur and Sun Tan shared their opinions with us about why they thought Che is amazing and unique and challenges they’ve found, which we recorded in a video.

Power-Interest

In the figure below we classify stakeholders of the Che project using the power-interest grid13. It indicates different levels of interest and power of stakeholders on the project. We then categorize the stakeholders into four groups in terms of how closely they need to be managed: key stakeholders which are to be managed closely, stakeholders to keep satisfied, ones that require minimal effort, and ones to keep informed.


Figure: Power vs. interest grid for the Eclipse Che project.

Context View

In this section we give a further overview of the scope of Eclipse Che and describe how it ispositioned within its context.

System Scope

Eclipse Che in its current form offers14:

  • containerised development workspaces with an integrated browser IDE and runtimes configurable to include all project runtime dependencies the developers need
  • a workspace server that orchestrates the workspace containers and deals with user management
  • plugins which add support for various development services, including IDE support for specific programming languages, frameworks, and developer tools like debuggers
  • an SDK for creating new plugins and shipping them by building new Che assemblies

Context Model

We expand on the details already discussed in previous chapters by looking at the entities theEclipse Che project interacts with and categorising them, presenting them in a diagram, and brieflydescribing each of the newly introduced ones.

Organisation

With Codenvy having been an important driving force of the project since the very beginning, thelist of the current project leaders is not surprising - TylerJewell is the Codenvy founder and former CEO, GennadyAzarenkov was the Codenvy CTO and now works at Red Hat, and BradMicklea moved from Codenvy to RedHat as a product manager.Furthermore, the project has two Eclipse Foundation assigned mentors.

Development

Eclipse Che is a Java project which uses Maven with several testing plugins as the projectbuilder and package manager. New releases of Che get built by a Jenkins CI server, whileSonarcloud is used for continuous code quality checking and Swagger.io for building anddocumenting APIs.

Connected services

Che runs on top of an application server and is deployed with Tomcat and PostgreSQL out of thebox. To build its IDE, Che relies either on Eclipse Orion (Che 6) or Eclipse Theia (Che 7).

Container orchestration is essential to install, run and manage Che, and the orchestratorscurrently supported are Docker, Kubernetes and OpenShift. For multi-user Che, Keycloak isused to handle user authentication and access management.

Project management

Most of the project management happens on GitHub, including issue tracking and version control.The project also maintains a GitHub Wiki that details the project management and developmentprocesses.

Licensed under / Follows

Eclipse Che is licensed under the Eclipse Public License 2.0 and its maintainers follow andenforce the Contributor Covenant Code of Conduct.

Community and support

The Eclipse Che community is active on multiple communication platforms. The project has an activemailing list, a Mattermost channel, maintains a blog presence on Medium, and organisesbiweekly videoconference Dev Meetings via BlueJeans. The project also organises an annual virtualuser conference CheConf.

Live

Technical Debt

Technical debt in Eclipse Che

The project is split up in several modules. This helps in keeping coupling low, because differentmodules can only interact if there is an explicit dependency defined in maven. Most classes arevery small, which helps in keeping cohesion high.

Running Sonarcloud on the source code of Che some interesting outliers arefound. One of these is ClientTestingMessage in the testing plugin. This class violates SOLID bykeeping a reference to all classes that inherit this class. This can also cause further problems.

Another class which grabs the attention is JGitConnection, which is by far the largest class inthe project. This class is a very large adapter class for jgit, itimplements everything needed for git interaction in a single class.

Vien

The CronExpression class has the largest amount of technical debt according to Sonarcloud. Thisclass is very large, where it probably should not be. There are methods with very highcomplexity, there is duplicated code and possible null pointers. Given that this class implementssomething very specific that has nothing to do with this project, it should probably be moved to adependency.

The MenuLockLayer and TextBox classes have a D and E rating respectively. Both these classesextend a class from GWT. The main issue with these classes accordingto Sonarcloud is that the inheritance tree is too deep (larger than 5). It wouldn’t be viable tofix these issues, because the root of the issue lies in the dependency. For the next version of Che,these classes are deprecated because a new IDE is introduced.

error prone is used to report warnings about common errors.

Test debt in Eclipse Che

Eclipse Che is tested with JUnit (4900 Unit tests for individual modules) and Selenium (640Integration tests between modules). The Selenium end-to-end tests test Che in a browser with anautomated user. Building and running the tests takes about three hours. The end-to-end tests takeabout 2 hours to complete. These tests are only executed in pull requests when it is needed. Thereare also nightly builds which allows QA to test changes rapidly. During development the contributorSkorikSergey focusses on proper testing and gives advice on this for other contributors in PullRequests.

The test reports are run in a Jenkins Continuous Integration (CI)environment. In addition, a SonarCloud environment is available, buthasn’t been used since November2018. Code coverageisn’t taken directly into account into the Jenkins CI or SonarCloud environment.

We performed an analysis on the tested modules and the reports generated by a recent SonarCloudanalysis by our team. In the testing degree Figure below, the lines of code are plotted against the number oftests written for that module. The size of the bubble indicates the relative number of code smellsreported by SonarCloud.

In general, for the tested modules it is found that modules with more lines of code are tested withmore tests as well. Modules which are tested with relatively more tests tend to show a lesserdegree of code smells (docker-client, infrastructure-kubernetes) than modules with a lower number oftests (che-core-api-core, che-core-commons-gwt).

Eclipse Che 7 Docker Image

In addition, it is observed that there exist quite some tests for the modules responsible forpermissions. This makes sense as assurance of the access security is very important to gain trustfrom users. Bugs which lead to unauthorized access often lead to higher damage than functionalbugs. On the other side, plugin modules are barely or not tested at all. The choice for lesstesting might lie in the more trivial code involved.

Our Sonarcloud analysis showed that in some modules there exists some code duplication. For example,in the che-core-api-dto module 21.1% duplication is observed. However, additional analysis indicatedthat this module is generating java code and deduplication in this module will likely lead to lessmaintainable code. Lastly, it is found that for the Selenium tests, additional tests exist whichtest whether the Selenium tests behave accordingly. These additional tests test whether mockedclasses have the right intended behaviour for example.

In general, testing is performed well in the project. Actions which can improve the testingapproach is to enable automatic coverage tools. This provides an indication of what is and isn’ttested in the project. Furthermore, it can be smart to make more use of the SonarCloud environment.

Discussions about technical debt

Eclipse Che 7 Documentation

There are sprint issues in the repository which are created for every two weeks. These issues havea specific section on Technical Debt. In this section, there is a list of issues which areconsidered technical debt and that should be fixed in that sprint. Issues themselves are not markedas containing technical debt.

There are about 150 TODO comments in the source code. Most of these were added in 2017 and thereare two authors who have contributed 90% of the TODO comments. It seems that most of these TODOcomments don’t require some implementation as they have already been in the code for almost twoyears. Several comments are in the GWT IDE, which is no longer under active development and isa candidate for being moved to another repository.

Evolution of technical debt

The Eclipse Che team has made a recent move from GWT to Theia as IDE with the release of Che 7. Theia is maintained in a separate repository and can also be used outside of Che. Thismovement makes a coupling with Che very low and better maintainable. The team has moved to theVSCode plugin protocol as well. This enables better modularisation for plugins. Bothmovements help in lower technical dept.

Not much historical data is easily available as SonarCloud isn’t run very often and older CI buildsaren’t preserved long. It is found that tests are continuously developed duringdevelopment.Additionally, it is found that during development the number of code smells is also highlyreduced.

To get some more insight into the evolution of the project, we ran several major releases in our sonarcloud environment 4.0.0, 5.0.0, 6.0.0, 7.0.0-beta-1.0.

It was observed that the number of code smells highly dropped from Che version 5 onwards. Betweenversion 6 and 7, a major drop in code smells can be attributed to the removal of forked code fromEclipse JDT in version 6.13.0. In addition, other dependencies are removed as well due to the movefrom GWT to Theia.

Development view

Module structure

Eclipse Che source code is modularised and uses Maven to manage the dependencies between themodules. On a high level, we analyse the module dependencies by looking at the way the Che assemblybinaries of the main system components are built. The components we considered are thus: the Cheworkspace master (that is, the Che server), workspace loader, workspace agents (that run and managea workspace instance), IDE, and User Dashboard.

From a top level (in the Figure below), both the workspace server and the agents make use of the Che Coremodule which contains shared APIs and libraries, while the Dashboard is a self-contained Web-basedmodule. The workspace agents make extensive use of Plugin modules which support IDE and otherworkspace services. We follow the dependencies of both the workspace server and the agents furtherin Figures below.

Common design model

Core APIs

The Core APIs used in Eclipse Che are in the core/che-core-api-core module, includingdefinitions of JSON-RPC and REST operations, event subscription, unsubscription and notification,web socket, proxy authenticators and password encryptors, and standard API exception formats.

Database interaction

Database interactions are defined in the core/che-core-db module — for example, database initialization and termination, SQL script creation and migration, common database error codes as well as data source tracing methods.

Shared libraries

Most of the shared libraries for the server, agents and plugins are in the core/commons module. Some examples of these libraries include ones that handle Single Sign-On (SSO) token extraction and authentication exceptions, JSON parsing and writing, and e-mail services.

Logging and instrumentation

Che uses SLF4J and Logback for logging within the browser IDE and on server-side, respectively. Che also exposes metrics in a format that can be consumed by a Prometheus server and visualised in Grafana - this includes metrics from the JVM, the class loader, and the Tomcat server. Che also supports the collection of end-to-end trace data by deploying a Jaeger server.

Third-party libraries

Eclipse Che relies on a set of third-party libraries each of which serves independently, such as Google Web Toolkit and Tomcat, SLF4J for message logging, Swagger for API design, and Javax for email services and web socket applications.

Design pattern: “Sidecar container”

In this cloud development design pattern, the sidecar containers are attached to the parent application container and are used to provide supporting features to the main application. Sidecar containers can follow their own development and runtime lifecycle, allowing for easy upgrades and modifications.

This design pattern became prominent with the new Che 7. Previously, all the dependencies required for active development within a workspace had to be injected into the main workspace container image. This meant that the development container image used in the workspace was not identical to the production image anymore. To address this and avoid having to modify the production image clone, the sidecar container pattern was employed in order to organise the workspace containerisation.

Eclipse Che 7

The various services that used to be parts of a workspace have thus been split into separate containers (as seen in the Figure below), providing further isolation and encapsulation. The main workspace container does not need to have extra plugins installed anymore, as any additional workspace services and plugins will run in separate sidecars.

Plugin brokers

Eclipse Che 7 Helm Chart

Plugin brokers are special services that will, given a specific plugin metadata description, gather all the information about definitions already available on the Che server to and prepare the workspace for the plugin installation. This includes, for example, downloading and unpacking required files, returning a set of endpoints, containers (and even editors) for the plugin. The main goal of using a plugin broker is to decouple the Che plugin setup from the Che server itself, allowing Che to support different kinds of plugins without having to modify the Che server code for every new kind of plugin added.

Codeline model

Source code structure

We describe the overall, high-level structure of the source code repositories used by the project. The main codebase of course resides in the main Che GitHub repository; however, some of the source code the project depends on is contained in other repositories in order to allow for it to be managed separately.

Main Repo

The main Che source repository on GitHub has the following high-levelstructure11, which generally follows the way Che is split into submodules.

DirectoryDescription
/Root directory
/agentsWorkspace software (web terminal, language servers, ssh server)
/assemblyGenerates binary assemblies of Che
/coreShared libraries for server, agents, and plugins
/dashboardJavaScript app user management
/dockerfilesDocker images to run Che, CLI, & utilities
/ideBrowser IDE
/pluginsIDE & workspace agent plugins
/samplesCode templates for fresh workspaces
Other Repos

Some of the Che dependencies are managed in other repositories owned either by the EclipseFoundation or Codenvy. This is done for multiple reasons11 — thesedependencies are either forks of other relevant projects, contain libraries that follow a differenttagging lifecycle than Che, or they contain very large files.

RepositoryDescription
eclipse/che-devDev resources - code style, license headers
eclipse/che-dockerfilesAll project’s Dockerfiles
eclipse/che-docsOfficial Che docs
eclipse/che-libDependencies forked from elsewhere (antlr, Orion, Tomcat, Logback, Swagger…)
eclipse/che-parentMaven root parent POM, manages dependencies
eclipse/che-theiaNew Che 7 IDE
codenvy/che-installerWindows and JAR installers
codenvy/che-tutorialsSDK examples and tutorials
che-incubator/chectlCommand line interface for Che
redhat-developer/rh-cheEclipse Che on OpenShift
redhat-developer/devfileChe 7 devfile specification

The source code for the official Eclipse Che website is tracked on the Eclipse Foundation git repository:

Build - Integrate - Test - Release Cycle

Once it’s clear where and how the project’s source code is stored, a pipeline has to be designedwhich takes the source code, builds it and tests it in order to finally bring it to release-readyshape. In this section we discuss how Che tackles this by describing how the project is built,changes integrated and tested stages, but also how the new versions get released.

Building Che

Che manages dependencies and builds the project with Apache Maven.Docker is used to provide container images that contain Che and all its dependencies. In addition,the Web-based user dashboard also makes use of [yarn](https://yarnpkg.com/en/], webpack and gulp.js for package management andbuilding, respectively.

Eclipse Che 7 Mau

Continuous integration

Continuous integration of committed code changes is executed on a Jenkinsserver hosted by Codeenvy. The Eclipse Che project runs severalJenkins CI jobs which are either “plain” builds (CI builds on git push to master, PR buildstriggered via PR comments, nightly builds) or specialised quality assurance builds with furthertesting (ran nightly, for a release candidate, or for the final release version).

Testing

Below we give an overview of the kinds of automated testing done when working on Che.

Test / analysis typeUsed by Che
Unit testingJUnit, TestNG at build time
Integration testingJUnit, TestNG at build time
Functional testingSelenium
Static analysisFindBugs, Error Prone at build time
Code styleMaven formatter plugin
Continuous code qualitySonarcloud

Unit and integration tests are run at build time using the Surefire plugin for Maven. Staticanalysis is also integrated into the build phase with both FindBugs and Error Prone checking forcompile-time detectable Java bugs. Code style is checked using a Maven plugin that checks forcompliance with Google Java style formatting.

Further quality assurance is done via functional and end-to-end testing using Selenium.

Sonarcloud has been used for continuous static analysis of Che releases between versions 6.2 and6.14 (the last check was done in November 2018). It is unclear why continuous code quality checksdo not seem to be run on a regular basis anymore.

Release process

Successfully built and tested new versions of Eclipse Che are released at the end of each 2-3 weekdevelopment cycle (“sprint”). The release process itself is automated and integrated into thestandard CI pipeline. Che binaries are tagged and compiled from release version source code usingMaven, whereas Docker is used to build and tag container images. If blocker bugs are found duringthe final quality assurance phase, the release can be blocked and postponed until the end of thenext sprint.

Configuration management

Software configuration management prescribes how changes are tracked and managed in order to ensurethat repeatability and traceability are possible when collaborating on a software project. Here wedetail the tooling and configuration structures employed by the Che team to support the developmentlifecycle.

Tooling

We first specify the configuration management tooling used by the Che team. We categorise themfollowing Berczuk’s list of tools needed forconfiguration management.

Tool typeUsed by the Che team
Version controlGit
Build ToolMaven
CI ServerJenkins
Artefact RepoNexus
Doc SystemGitHub Wiki
GitHub Configuration Structures

The Che team uses GitHub to track and control the development of lifecycle. We identify the type ofcodelines used and their respective GitHub branches.

There are three types of codelines used:

  • Mainline: The master branch containing the latest code which is well-tested and stable (as reported by the CI system),
  • Active development lines: Multiple branches where new features or bug fixes are worked on (are “in progress” and are allowed to be failing)
  • Release line: One branch at a time which contains the source code of the latest Che release.

The active development lines can live either in the main repository if the authors have contributoraccess or in project forks. The latter is discouraged, however, when collaborating on long-livedfeature branches - it is easier to track changes if all the development happens on main repobranches. In addition, feature branches have to be named after the matching GitHub issue number andmust be removed after they are merged to mainline.

Eclipse

When preparing to release a new version of the software, a release branch is created from themaster branch on the release candidate commit. Any potential bugs found after the release are fixedon this release branch and the branch itself is reused if a bugfix release is necessary. Once a newrelease is in progress, the previous release branch gets removed.

The Che team does not make extensive use of tagging. The only tags used are release versionnumbers labelling the respective commits where the past and the current release lines branched off.

Functional View

Eclipse Che consists of several components which together form the developmentenvironment14. The functions of these components in the architecture, together with theirinteractions are depicted in the functional view. Projects are contained in workspaces which arehosted in a workspace server. These workspaces can subsequently be accessed by browser-based IDEs.In addition, plugins can be implemented for which a Software Development Kit (SDK) is available.

Workspace server

The workspace server of Eclipse Che is installed on a Server infrastructure (for example ApacheTomCat) and is the central access point for the workspaces it maintains. Single or multiple userscan access workspace via a Restful API connection. The different workspaces are isolated from eachother and cannot interact.

Workspaces

Workspaces are used by one or multiple users to develop projects. A workspace can have any numberof projects which can be connected to version control repositories (like git, mercurial orsubversion) as well. Every workspace can be accessed through an IDE specific for that workspace viathe browser. An API is used for interaction between the browser IDE and the workspace. In addition,access via desktop IDEs is possible as well. Language services enable development support fordifferent languages of choice. Every workspace has one or multiple runtimes, using a hostenvironment. These runtimes are used to build, run, and debug projects like one would do locallywith for example maven. Workspaces can be exported to move them from one Che server to another. Inaddition, it is possible to save and restore snapshots via a snapshot registry.

Server infrastructure

Eclipse Che 7 Docker

Server infrastructures are used to make environments for the Che Server as well as environments forthe workspace runtimes to run their code in. The server environments make use of either Docker orOpenShift to work. Users can either set up these on their local PC or on a central server. Localinstallations can be used by single users for small projects. Such an installation is easier tostart with as no login is required15. Server installations can be used by multipleusers in development teams in organizations. In addition, it is also possible to use a server fromRedhat in the form of Software as a Service (SaaS).

SDK

Eclipse Che is made so it can be extended easily. Plugins can be made by plugin providers foreither the Che server, a workspace (also called an agent) or the browser IDE. For the development,a Software Development Kit (SDK) is available which enables the packaging plugins into assembliesfor use in production. Several plugins are already available for elements like ones for languages,frameworks and tools.

Conclusions

We have analyzed the architecture of Eclipse Che, an open-source cloud IDE. It offers containerizeddevelopment workspaces and plugins to support various development services. Codenvy, Red Hat andEclipse Foundation are considered the most important stakeholders. We have identified integratorsand pull request merge strategies by pull request analysis. Each pull request needs to pass thetests and code reviews before a maintainer approves its merge. The technical debt analysis showsthat the team is working hard to remove components from project which have a large amount oftechnical debt. We also observed that tests help properly in reducing code smells.

The development view provided us with more insights into the project. We have analyzed the modulestructure, the codeline model and the common design model. Here the sidecar is one of the mostinteresting design patterns used. The functional view depicts the components of Eclipse Che andtheir interactions.

References

Eclipse Che 7

  1. Benjamin Mestrallet. From eXo Cloud IDE to Codenvy Raising 9 Million Dollars: A Brief History, 2013. exoplatform.com↩↩2

  2. https://www.eclipse.org/org/foundation/] ↩

  3. https://www.eclipse.org/ecd/ ↩

  4. Tyler Jewell, Introducing Eclipse Che and Eclipse Cloud Development, 2014. codenvy.com↩↩23

  5. Tyler Jewell, Red Hat To Acquire Codenvy, 2017. codenvy.com↩

  6. Tyler Jewell, OpenShift.io and Eclipse Che, 2017. eclipse.org↩

  7. Eclipse Che: Release}, 2019. https://github.com/eclipse/che/releases ↩

  8. Che Wiki: Development Process, 2019. https://github.com/eclipse/che/wiki/Development-Process ↩↩234567

  9. Nick Rozanski and Eoin Woods. Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley, 2011. ↩

  10. Software Systems Architecture, 2019, https://www.viewpoints-and-perspectives.info ↩

  11. Che Wiki: Development Workflow}, 2019, https://github.com/eclipse/che/wiki/Development-Workflow ↩↩234

  12. Che Wiki: Community Meetings, 2019, https://github.com/eclipse/che/wiki/Che-Dev-Meetings ↩

  13. Aburey Mendelow, Stakeholder mapping. Proceedings of the 2nd international conference on information systems, Cambridge, MA, 1991. ↩

  14. https://github.com/eclipse/che-docs] ↩↩2

  15. Single and Multi-User Che, 2019. https://www.eclipse.org/che/docs/che-6/single-multi-user.html ↩