Chapter 4. Customizing developer environments

Red Hat CodeReady Workspaces is an extensible and customizable developer-workspaces platform.

You can extend Red Hat CodeReady Workspaces in three different ways:

  • Alternative IDEs provide specialized tools for Red Hat CodeReady Workspaces. For example, a Jupyter notebook for data analysis. Alternate IDEs can be based on Eclipse Theia or any other IDE (web or desktop based). The default IDE in Red Hat CodeReady Workspaces is Che-Theia.
  • Che-Theia plug-ins add capabilities to the Che-Theia IDE. They rely on plug-in APIs that are compatible with Visual Studio Code. The plug-ins are isolated from the IDE itself. They can be packaged as files or as containers to provide their own dependencies.
  • Stacks are pre-configured CodeReady Workspaces workspaces with a dedicated set of tools, which cover different developer personas. For example, it is possible to pre-configure a workbench for a tester with only the tools needed for their purposes.

Figure 4.1. CodeReady Workspaces extensibility

A user can extend CodeReady Workspaces by using self-hosted mode, which CodeReady Workspaces provides by default.

4.1. What is a Che-Theia plug-in

A Che-Theia plug-in is an extension of the development environment isolated from the IDE. Plug-ins can be packaged as files or containers to provide their own dependencies.

Extending Che-Theia using plug-ins can enable the following capabilities:

  • Language support: Extend the supported languages by relying on the Language Server Protocol.
  • Debuggers: Extend debugging capabilities with the Debug Adapter Protocol.
  • Development Tools: Integrate your favorite linters, and as testing and performance tools.
  • Menus, panels, and commands: Add your own items to the IDE components.
  • Themes: Build custom themes, extend the UI, or customize icon themes.
  • Snippets, formatters, and syntax highlighting: Enhance comfort of use with supported programming languages.
  • Keybindings: Add new keymaps and popular keybindings to make the environment feel natural.

4.1.1. Features and benefits of Che-Theia plug-ins

FeaturesDescriptionBenefits

Fast Loading

Plug-ins are loaded at runtime and are already compiled. IDE is loading the plug-in code.

Avoid any compilation time. Avoid post-installation steps.

Secure Loading

Plug-ins are loaded separately from the IDE. The IDE stays always in a usable state.

Plug-ins do not break the whole IDE if it has bugs. Handle network issue.

Tools Dependencies

Dependencies for the plug-in are packaged with the plug-in in its own container.

No-installation for tools. Dependencies running into container.

Code Isolation

Guarantee that plug-ins cannot block the main functions of the IDE like opening a file or typing

Plug-ins are running into separate threads. Avoid dependencies mismatch.

VS Code Extension Compatibility

Extend the capabilities of the IDE with existing VS Code Extensions.

Target multiple platform. Allow easy discovery of Visual Studio Code Extension with required installation.

4.1.2. Che-Theia plug-in concept in detail

Red Hat CodeReady Workspaces provides a default web IDE for workspaces: Che-Theia. It is based on Eclipse Theia. It is a slightly different version than the plain Eclipse Theia one because there are functionalities that have been added based on the nature of the Red Hat CodeReady Workspaces workspaces. This version of Eclipse Theia for CodeReady Workspaces is called Che-Theia.

You can extend the IDE provided with Red Hat CodeReady Workspaces by building a Che-Theia plug-in. Che-Theia plug-ins are compatible with any other Eclipse Theia-based IDE.

4.1.2.1. Client-side and server-side Che-Theia plug-ins

The Che-Theia editor plug-ins let you add languages, debuggers, and tools to your installation to support your development workflow. Plug-ins run when the editor completes loading. If a Che-Theia plug-in fails, the main Che-Theia editor continues to work.

Che-Theia plug-ins run either on the client side or on the server side. This is a scheme of the client and server-side plug-in concept:

Figure 4.2. Client and server-side Che-Theia plug-ins

The same Che-Theia plug-in API is exposed to plug-ins running on the client side (Web Worker) or the server side (Node.js).

4.1.2.2. Che-Theia plug-in APIs

For the purpose of providing tool isolation and easy extensibility in Red Hat CodeReady Workspaces, the Che-Theia IDE has a set of plug-in APIs. The APIs are compatible with Visual Studio Code extension APIs. In most cases, Che-Theia can run VS Code extensions as its own plug-ins.

When developing a plug-in that depends on or interacts with components of CodeReady Workspaces workspaces (containers, preferences, factories), use the CodeReady Workspaces APIs embedded in Che-Theia.

4.1.2.3. Che-Theia plug-in capabilities

Che-Theia plug-ins have the following capabilities:

Plug-inDescriptionRepository

CodeReady Workspaces Extended Tasks

Handles the CodeReady Workspaces commands and provides the ability to start those into a specific container of the workspace.

Task plug-in

CodeReady Workspaces Extended Terminal

Allows to provide terminal for any of the containers of the workspace.

Extended Terminal extension

CodeReady Workspaces Factory

Handles the Red Hat CodeReady Workspaces Factories

Workspace plug-in

CodeReady Workspaces Container

Provides a container view that shows all the containers that are running in the workspace and allows to interact with them.

Containers plug-in

Dashboard

Integrates the IDE with the Dashboard and facilitate the navigation.

Che-Theia Dashbord extension

CodeReady Workspaces APIs

Extends the IDE APIs to allow interacting with CodeReady Workspaces-specific components (workspaces, preferences).

Che-Theia API extension

4.1.2.4. VS Code extensions and Eclipse Theia plug-ins

A Che-Theia plug-in can be based on a VS Code extension or an Eclipse Theia plug-in.

A Visual Studio Code extension
To repackage a VS Code extension as a Che-Theia plug-in with its own set of dependencies, package the dependencies into a container. This ensures that Red Hat CodeReady Workspaces users do not need to install the dependencies when using the extension. See Section 4.2, “Adding a VS Code extension to a workspace”.
An Eclipse Theia plug-in
You can build a Che-Theia plug-in by implementing an Eclipse Theia plug-in and packaging it to Red Hat CodeReady Workspaces.

4.1.3. Che-Theia plug-in metadata

Che-Theia plug-in metadata is information about individual plug-ins for the plug-in registry.

The Che-Theia plug-in metadata, for each specific plug-in, is defined in a meta.yaml file.

Here is an overview of all fields that can be available in plugin meta YAML files. This document represents the Plugin meta YAML structure version 3.

The che-plugin-registry repository contains:

Table 4.1. meta.yml

apiVersion

Version 2 and higher where version is 1 supported for backwards compatibility

category

Available: Category must be set to one of the followings: Editor, Debugger, Formatter, Language, Linter, Snippet, Theme, Other

description

Short description of plugin’s purpose

displayName

Name shown in user dashboard

deprecate

Optional; section for deprecating plugins in favor of others

* autoMigrate - boolean

* migrateTo - new org/plugin-id/version, for example redhat/vscode-apache-camel/latest

firstPublicationDate

Not required to be present in YAML, as if not present, it will be generated during Plugin Registry dockerimage build

latestUpdateDate

Not required to be present in YAML, as if not present, it will be generated during Plugin Registry dockerimage build

icon

URL of an SVG or PNG icon

name

Name (no spaces allowed), must match [-a-z0-9]

publisher

Name of the publisher, must match [-a-z0-9]

repository

URL for plugin repository, for example, GitHub

title

Plugin title (long)

type

Che Plugin, VS Code extension

version

Version information, for example: 7.5.1, [-.a-z0-9]

spec

Specifications (see below)

Table 4.2. spec attributes

endpoints

Optional; plugin endpoint. See Section 3.2.4.2.19, “Endpoints”

containers

Optional; sidecar containers for the plug-in. Che Plugin and VS Code extension supports only one container

initContainers

Optional; sidecar init containers for the plug-in

workspaceEnv

Optional; environment variables for the workspace

extensions

Optional; Attribute that is required for VS Code and Che-Theia plug-ins in a form list of URLs to plug-in artefacts, such as .vsix or .theia files

Table 4.3. spec.containers. Notice: spec.initContainers has absolutely the same container definition.

name

Sidecar container name

image

Absolute or relative container image URL

memoryLimit

OpenShift memory limit string, for example 512Mi

memoryRequest

OpenShift memory request string, for example 512Mi

cpuLimit

OpenShift CPU limit string, for example 2500m

cpuRequest

OpenShift CPU request string, for example 125m

env

List of environment variables to set in the sidecar

command

String array definition of the root process command in the container

args

String array arguments for the root process command in the container

volumes

Volumes required by the plug-in

ports

Ports exposed by the plug-in (on the container)

commands

Development commands available to the plug-in container

mountSources

Boolean flag to bound volume with source code /projects to the plug-in container

initContainers

Optional; init containers for sidecar plugin

Lifecycle

Container lifecycle hooks. See lifecycle description

Table 4.4. spec.containers.env and spec.initContainers.env attributes. Notice: workspaceEnv has absolutely the same attributes

name

Environment variable name

value

Environment variable value

Table 4.5. spec.containers.volumes and spec.initContainers.volumes attributes

mountPath

Path to the volume in the container

name

Volume name

ephemeral

If true, the volume is ephemeral, otherwise the volume is persisted

Table 4.6. spec.containers.ports and spec.initContainers.ports attributes

exposedPort

Exposed port

Table 4.7. spec.containers.commands and spec.initContainers.commands attributes

name

Command name

workingDir

Command working directory

command

String array that defines the development command

Table 4.8. spec.endpoints attributes

name

Name (no spaces allowed), must match [-a-z0-9]

public

true, false

targetPort

Target port

attributes

Endpoint attributes

Table 4.9. spec.endpoints.attributes attributes

protocol

Protocol, example: ws

type

ide, ide-dev

discoverable

true, false

secure

true, false. If true, then the endpoint is assumed to listen solely on 127.0.0.1 and is exposed using a JWT proxy

cookiesAuthEnabled

true, false

requireSubdomain

true, false. If true, the endpoint is exposed on subdomain in single-host mode.

Table 4.10. spec.containers.lifecycle and spec.initContainers.lifecycle attributes

postStart

The postStart event that runs immediately after a Container is started. See postStart and preStop handlers

* exec: Executes a specific command, resources consumed by the command are counted against the Container

* command: ["/bin/sh", "-c", "/bin/post-start.sh"]

preStop

The preStop event that runs before a Container is terminated. See postStart and preStop handlers

* exec: Executes a specific command, resources consumed by the command are counted against the Container

* command: ["/bin/sh", "-c", "/bin/post-start.sh"]

Example meta.yaml for a Che-Theia plug-in: the CodeReady Workspaces machine-exec Service

  apiVersion: v2
  publisher: eclipse
  name: che-machine-exec-plugin
  version: 7.9.2
  type: Che Plugin
  displayName: CodeReady Workspaces machine-exec Service
  title: Che machine-exec Service Plugin
  description: CodeReady Workspaces Plug-in with che-machine-exec service to provide creation terminal
    or tasks for Eclipse CHE workspace containers.
  icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
  repository: https://github.com/eclipse/che-machine-exec/
  firstPublicationDate: "2020-03-18"
  category: Other
  spec:
    endpoints:
     -  name: "che-machine-exec"
        public: true
        targetPort: 4444
        attributes:
          protocol: ws
          type: terminal
          discoverable: false
          secure: true
          cookiesAuthEnabled: true
    containers:
     - name: che-machine-exec
       image: "quay.io/eclipse/che-machine-exec:7.9.2"
       ports:
         - exposedPort: 4444
       command: ['/go/bin/che-machine-exec', '--static', '/cloud-shell', '--url', '127.0.0.1:4444']

Example meta.yaml for a VisualStudio Code extension: the AsciiDoc support extension

apiVersion: v2
category: Language
description: This extension provides a live preview, syntax highlighting and snippets for the AsciiDoc format using Asciidoctor flavor
displayName: AsciiDoc support
firstPublicationDate: "2019-12-02"
icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
name: vscode-asciidoctor
publisher: joaompinto
repository: https://github.com/asciidoctor/asciidoctor-vscode
title: AsciiDoctor Plug-in
type: VS Code extension
version: 2.7.7
spec:
  extensions:
  - https://github.com/asciidoctor/asciidoctor-vscode/releases/download/v2.7.7/asciidoctor-vscode-2.7.7.vsix

4.1.4. Che-Theia plug-in lifecycle

Every time a user starts a Che workspace, a Che-Theia plug-in life cycle process starts. The steps of this process are as follows:

  1. CodeReady Workspaces server checks for plug-ins to start from the workspace definition.
  2. CodeReady Workspaces server retrieves plug-in metadata, recognizes each plug-in type, and stores them in memory.
  3. CodeReady Workspaces server selects a broker according to the plug-in type.
  4. The broker processes the installation and deployment of the plug-in. The installation process of the plug-in differs for each specific broker.
Note

Plug-ins exist in various types. A broker ensures the success of a plug-in deployment by meeting all installation requirements.

Figure 4.3. Che-Theia plug-in lifecycle

Before a CodeReady Workspaces workspace is launched, CodeReady Workspaces server starts the workspace containers:

  1. The Che-Theia plug-in broker extracts the information about sidecar containers that a particular plug-in needs from the .theia file.
  2. The broker sends the appropriate container information to CodeReady Workspaces server.
  3. The broker copies the Che-Theia plug-in to a volume to have it available for the Che-Theia editor container.
  4. CodeReady Workspaces server then starts all the containers of the workspace.
  5. Che-Theia starts in its container and checks the correct folder to load the plug-ins.

A user experience with Che-Theia plug-in lifecycle

  1. When a user opens a browser tab with Che-Theia, Che-Theia starts a new plug-in session with:

    • Web Worker for frontend
    • Node.js for backend
  2. Che-Theia notifies all Che-Theia plug-ins with the start of the new session by calling the start() function for each triggered plug-in.
  3. A Che-Theia plug-in session runs and interacts with the Che-Theia backend and frontend.
  4. When the user closes the Che-Theia browser tab, or the session ended on a timeout limit, Che-Theia notifies all plug-ins with the stop() function for each triggered plug-in.

4.1.5. Embedded and remote Che-Theia plug-ins

Developer workspaces in Red Hat CodeReady Workspaces provide all dependencies needed to work on a project. The application includes the dependencies needed by all the tools and plug-ins used.

Based on the required dependencies, Che-Theia plug-in can run as:

  • Embedded, also know as local
  • Remote

4.1.5.1. Embedded (local) plug-ins

The Embedded plug-ins are plug-ins without specific dependencies that are injected into the Che-Theia IDE. These plug-ins use the Node.js runtime, which runs in the IDE container.

Examples:

  • Code linting
  • New set of commands
  • New UI components

To include a Che-Theia plug-in or VS Code extension, define a URL to the plug-in .theia archive binary in the meta.yaml file. See Section 4.2, “Adding a VS Code extension to a workspace”

When starting a workspace, CodeReady Workspaces downloads and unpacks the plug-in binaries and includes them in the Che-Theia editor container. The Che-Theia editor initializes the plug-ins when it starts.

4.1.5.2. Remote plug-ins

The plug-in relies on dependencies or it has a back end. It runs in its own sidecar container, and all dependencies are packaged in the container.

A remote Che-Theia plug-in consist of two parts:

  • Che-Theia plug-in or VS Code extension binaries. The definition in the meta.yaml file is the same as for embedded plug-ins.
  • Container image definition, for example, eclipse/che-theia-dev:nightly. From this image, CodeReady Workspaces creates a separate container inside a workspace.

Examples:

  • Java Language Server
  • Python Language Server

When starting a workspace, CodeReady Workspaces creates a container from the plug-in image, downloads and unpacks the plug-in binaries, and includes them in the created container. The Che-Theia editor connects to the remote plug-ins when it starts.

4.1.5.3. Comparison matrix

  • Embedded plug-ins are those Che-Theia plug-ins or VS Code extensions that do not require extra dependencies inside its container.
  • Remote plug-ins are containers that contain a plug-in with all required dependencies.

Table 4.11. Che-Theia plug-in comparison matrix: embedded vs remote

 Configure RAM per plug-inEnvironment dependenciesCreate separated container

Remote

TRUE

Plug-in uses dependencies defined in the remote container.

TRUE

Embedded

FALSE (users can configure RAM for the whole editor container, but not per plug-in)

Plug-in uses dependencies from the editor container; if container does not include these dependencies, the plug-in fails or does not function as expected.

FALSE

Depending on your use case and the capabilities provided by your plug-in, select one of the described running modes.

4.1.6. Remote plug-in endpoint

Red Hat CodeReady Workspaces has a remote plug-in endpoint service to start VS Code Extensions and Che-Theia plug-ins in separate containers. Red Hat CodeReady Workspaces injects the remote plug-in endpoint binaries into each remote plug-in container. This service starts remote extensions and plug-ins defined in the plug-in meta.yaml file and connects them to the Che-Theia editor container.

The remote plug-in endpoint creates a plug-in API proxy between the remote plug-in container and the Che-Theia editor container. The remote plug-in endpoint is also an interceptor for some plug-in API parts, which it launches inside a remote sidecar container rather than an editor container. Examples: terminal API, debug API.

The remote plug-in endpoint executable command is stored in the environment variable of the remote plug-in container: PLUGIN_REMOTE_ENDPOINT_EXECUTABLE.

Red Hat CodeReady Workspaces provides two ways to start the remote plug-in endpoint with a sidecar image:

  • Defining a launch remote plug-in endpoint using a Dockerfile. To use this method, patch an original image and rebuild it.
  • Defining a launch remote plug-in endpoint in the plug-in meta.yaml file. Use this method to avoid patching an original image.

4.1.6.1. Defining a launch remote plug-in endpoint using Dockerfile

To start a remote plug-in endpoint, set the PLUGIN_REMOTE_ENDPOINT_EXECUTABLE environment variable in the Dockerfile.

Procedure

  • Start a remote plug-in endpoint using the CMD command in the Dockerfile:

    Dockerfile example

    FROM fedora:30
    
    RUN dnf update -y && dnf install -y nodejs htop && node -v
    
    RUN mkdir /home/jboss
    
    ENV HOME=/home/jboss
    
    RUN mkdir /projects \
        && chmod -R g+rwX /projects \
        && chmod -R g+rwX "${HOME}"
    
    CMD ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}

  • Start a remote plug-in endpoint using the ENTRYPOINT command in the Dockerfile:

    Dockerfile example

    FROM fedora:30
    
    RUN dnf update -y && dnf install -y nodejs htop && node -v
    
    RUN mkdir /home/jboss
    
    ENV HOME=/home/jboss
    
    RUN mkdir /projects \
        && chmod -R g+rwX /projects \
        && chmod -R g+rwX "${HOME}"
    
    ENTRYPOINT ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}

4.1.6.1.1. Using a wrapper script

Some images use a wrapper script to configure permissions inside the container. The Dockertfile ENTRYPOINT command defines this script, which executes the main process defined in the CMD command of the Dockerfile.

CodeReady Workspaces uses images with a wrapper script to provide permission configurations to different infrastructures protected by advanced security. OpenShift Container Platform is an example of such an infrastructure.

  • Example of a wrapper script:

    #!/bin/sh
    
    set -e
    
    export USER_ID=$(id -u)
    export GROUP_ID=$(id -g)
    
    if ! whoami >/dev/null 2>&1; then
        echo "${USER_NAME:-user}:x:${USER_ID}:0:${USER_NAME:-user} user:${HOME}:/bin/sh" >> /etc/passwd
    fi
    
    # Grant access to projects volume in case of non root user with sudo rights
    if [ "${USER_ID}" -ne 0 ] && command -v sudo >/dev/null 2>&1 && sudo -n true > /dev/null 2>&1; then
        sudo chown "${USER_ID}:${GROUP_ID}" /projects
    fi
    
    exec "$@"
  • Example of a Dockerfile with a wrapper script:

    Dockerfile example

    FROM alpine:3.10.2
    
    ENV HOME=/home/theia
    
    RUN mkdir /projects ${HOME} && \
        # Change permissions to let any arbitrary user
        for f in "${HOME}" "/etc/passwd" "/projects"; do \
          echo "Changing permissions on ${f}" && chgrp -R 0 ${f} && \
          chmod -R g+rwX ${f}; \
        done
    
    ADD entrypoint.sh /entrypoint.sh
    
    ENTRYPOINT [ "/entrypoint.sh" ]
    CMD ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}

    Explanation:

    • The container launches the /entrypoint.sh script defined in the ENTRYPOINT command of the Dockerfile.
    • The script configures the permissions and executes the command using exec $@.
    • CMD is the argument for ENTRYPOINT, and the exec $@ command calls ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}.
    • The remote plug-in endpoint then starts in the container after permission configuration.

4.1.6.2. Defining a launch remote plug-in endpoint in a meta.yaml file

Use this method to re-use images for starting a remote plug-in endpoint without any modifications.

Procedure

Modify the plug-in meta.yaml file properties command and args:

  • command - CodeReady Workspaces uses the command properties to override the Dockerfile#ENTRYPOINT value.
  • args - CodeReady Workspaces uses uses the args properties to override the Dockerfile#CMD value.
  • Example of a YAML file with the command and args properties modified:

    apiVersion: v2
    category: Language
    description: "Typescript language features"
    displayName: Typescript
    firstPublicationDate: "2019-10-28"
    icon: "https://www.eclipse.org/che/images/logo-eclipseche.svg"
    name: typescript
    publisher: che-incubator
    repository: "https://github.com/Microsoft/vscode"
    title: "Typescript language features"
    type: "VS Code extension"
    version: remote-bin-with-override-entrypoint
    spec:
      containers:
        - image: "example/fedora-for-ts-remote-plugin-without-endpoint:latest"
          memoryLimit: 512Mi
          name: vscode-typescript
          command:
            - sh
            - -c
          args:
            - ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}
      extensions:
        - "https://github.com/che-incubator/ms-code.typescript/releases/download/v1.35.1/che-typescript-language-1.35.1.vsix"
  • Modify args instead of command to use an image with a wrapper script pattern and to keep a call of the entrypoint.sh script:

    apiVersion: v2
    category: Language
    description: "Typescript language features"
    displayName: Typescript
    firstPublicationDate: "2019-10-28"
    icon: "https://www.eclipse.org/che/images/logo-eclipseche.svg"
    name: typescript
    publisher: che-incubator
    repository: "https://github.com/Microsoft/vscode"
    title: "Typescript language features"
    type: "VS Code extension"
    version: remote-bin-with-override-entrypoint
    spec:
      containers:
        - image: "example/fedora-for-ts-remote-plugin-without-endpoint:latest"
          memoryLimit: 512Mi
          name: vscode-typescript
          args:
            - sh
            - -c
            - ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}
      extensions:
        - "https://github.com/che-incubator/ms-code.typescript/releases/download/v1.35.1/che-typescript-language-1.35.1.vsix"

    Red Hat CodeReady Workspaces calls the entrypoint.sh wrapper script defined in the ENTRYPOINT command of the Dockerfile. The script executes [ ‘sh’, ‘-c”, ‘ ${PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}’ ] using the exec “$@” command.

Note

By modifying the command and args properties of the meta.yaml file, a user can:

  • Execute a service at a container start
  • Start a remote plug-in endpoint

To make these actions run at the same time:

  1. Start the service.
  2. Detach the process.
  3. Start the remote plug-in endpoint.

4.2. Adding a VS Code extension to a workspace

This section describes how to add a VS Code extension to a workspace using the CodeReady Workspaces Plugins panel or the workspace configuration.

Prerequisites

4.2.1. Adding a VS Code extension using the CodeReady Workspaces Plugins panel

Prerequisites

Procedure

To add a VS Code extension using the CodeReady Workspaces Plugins panel:

  1. Open the CodeReady Workspaces Plugins panel by pressing CTRL+SHIFT+J or navigate to View/Plugins.
  2. Change the current registry to the registry in which the VS Code extension was added.
  3. In the search bar, click the Menu button and then click Change Registry to choose the registry from the list. If the required registry is not in the list, add it using the Add Registry menu option. The registry link points to the plugins segment of the registry, for example: https://my-registry.com/v3/plugins/index.json.
  4. To update the list of plug-ins after adding a new registry link, use Refresh command from the search bar menu.
  5. Search for the required plug-in using the filter, and then click the Install button.
  6. Restart the workspace for the changes to take effect.

4.2.2. Adding a VS Code extension using the workspace configuration

Prerequisites

Procedure

To add a VS Code extension using the workspace configuration:

  1. Click the Workspaces tab on the Dashboard and select the workspace in which you want to add the plug-in. The Workspace <workspace-name> window is opened showing the details of the workspace.
  2. Click the devfile tab.
  3. Locate the components section, and add a new entry with the following structure:

     - type: chePlugin
       id:              1
    1
    ID format: <publisher>/<plug-inName>/<plug-inVersion>

    CodeReady Workspaces automatically adds the other fields to the new component.

    Alternatively, you can link to a meta.yaml file hosted on GitHub, using the dedicated reference field.

     - type: chePlugin
       reference:              1
    1
    https://raw.githubusercontent.com/<username>/<registryRepository>/v3/plugins/<publisher>/<plug-inName>/<plug-inVersion>/meta.yaml
  4. Restart the workspace for the changes to take effect.

4.3. Publishing metadata for a VS Code extension

To use a VS Code extension in a CodeReady Workspaces workspace, CodeReady Workspaces need to consume metadata describing the extension. The CodeReady Workspaces plugin registry is a static website publishing metadata for common VS Code extensions.

How to publish metadata for an additional extension, not available in the CodeReady Workspaces plugin registry using the extension configuration. meta.yaml file.

Prerequisite

  • If the VS Code extension requires it, the required associated container image is available.

Procedure

  1. Create a meta.yaml file.
  2. Edit the meta.yaml file and provide the necessary information. The file must have the following structure:

    apiVersion: v2                                                   1
    publisher: myorg                                                 2
    name: my-vscode-ext                                              3
    version: 1.7.2                                                   4
    type: value                                                      5
    displayName:                                                     6
    title:                                                           7
    description:                                                     8
    icon: https://www.eclipse.org/che/images/logo-eclipseche.svg     9
    repository:                                                     10
    category:                                                       11
    spec:
      containers:                                                   12
        - image:                                                    13
          memoryLimit:                                              14
          memoryRequest:                                            15
          cpuLimit:                                                 16
          cpuRequest:                                               17
      extensions:                                                   18
              - https://github.com/redhat-developer/vscode-yaml/releases/download/0.4.0/redhat.vscode-yaml-0.4.0.vsix
              - https://github.com/SonarSource/sonarlint-vscode/releases/download/1.16.0/sonarlint-vscode-1.16.0.vsix
    1
    Version of the file structure.
    2
    Name of the plug-in publisher. Must be the same as the publisher in the path.
    3
    Name of the plug-in. Must be the same as in path.
    4
    Version of the plug-in. Must be the same as in path.
    5
    Type of the plug-in. Possible values: Che Plugin, Che Editor, Theia plugin, VS Code extension.
    6
    A short name of the plug-in.
    7
    Title of the plug-in.
    8
    A brief explanation of the plug-in and what it does.
    9
    The link to the plug-in logo.
    10
    Optional. The link to the source-code repository of the plug-in.
    11
    Defines the category that this plug-in belongs to. Should be one of the following: Editor, Debugger, Formatter, Language, Linter, Snippet, Theme, or Other.
    12
    If this section is omitted, the VS Code extension is added into the Che-Theia IDE container.
    13
    The Docker image from which the sidecar container will be started. Example: theia-endpoint-image.
    14
    The maximum RAM which is available for the sidecar container. Example: "512Mi". This value might be overridden by the user in the component configuration.
    15
    The RAM which is given for the sidecar container by default. Example: "256Mi". This value might be overridden by the user in the component configuration.
    16
    The maximum CPU amount in cores or millicores (suffixed with "m") which is available for the sidecar container. Examples: "500m", "2". This value might be overridden by the user in the component configuration.
    17
    The CPU amount in cores or millicores (suffixed with "m") which is given for the sidecar container by default. Example: "125m". This value might be overridden by the user in the component configuration.
    18
    A list of VS Code extensions run in this sidecar container.
  3. Publish the meta.yaml file as an HTTP resource by creating a gist on GitHub or GitLab with a file content published there.

4.4. Testing a Visual Studio Code extension in CodeReady Workspaces

Visual Studio Code (VS Code) extensions work in a workspace. VS Code extensions can run in the Che-Theia editor container, or in their own isolated and preconfigured containers with their prerequisites.

This section describes how to test a VS Code extension in CodeReady Workspaces with workspaces and how to review the compatibility of VS Code extensions to check whether a specific API is available.

Note

The extension-hosting sidecar container and the use of the extension in a devfile are optional.

4.4.1. Testing a VS Code extension using GitHub gist

Each workspace can have its own set of plug-ins. The list of plug-ins and the list of projects to clone are defined in the devfile.yaml file.

For example, to enable an AsciiDoc plug-in from the Red Hat CodeReady Workspaces dashboard, add the following snippet to the devfile:

components:
 - id: joaopinto/vscode-asciidoctor/latest
   type: chePlugin

To add a plug-in that is not in the default plug-in registry, build a custom plug-in registry. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.7/html-single/administration_guide/index#customizing-the-registries_crw, or, alternatively, use GitHub and the gist service.

Prerequisites

  • A running instance of Red Hat CodeReady Workspaces. To install an instance of Red Hat CodeReady Workspaces, see Installing CodeReady Workspaces.
  • A GitHub account.

Procedure

  1. Go to the gist webpage and create a README.md file with the following description: Try Bracket Pair Colorizer extension in Red Hat CodeReady Workspaces and content: Example VS Code extension. (Bracket Pair Colorizer is a popular VS Code extension.)
  2. Click the Create secret gist button.
  3. Clone the gist repository by using the URL from the navigation bar of the browser:

    $ git clone https://gist.github.com/<your-github-username>/<gist-id>

    Example of the output of the git clone command

    git clone https://gist.github.com/benoitf/85c60c8c439177ac50141d527729b9d9 1
    Cloning into '85c60c8c439177ac50141d527729b9d9'...
    remote: Enumerating objects: 3, done.
    remote: Counting objects: 100% (3/3), done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.

    1
    Each gist has a unique ID.
  4. Change the directory:

    $ cd <gist-directory-name> 1
    1
    Directory name matching the gist ID.
  5. Download the plug-in from the VS Code marketplace or from its GitHub page, and store the plug-in file in the cloned directory.
  6. Create a plugin.yaml file in the cloned directory to add the definition of this plug-in.

    Example of the plugin.yaml file referencing the .vsix binary file extension

    apiVersion: v2
    publisher: CoenraadS
    name: bracket-pair-colorizer
    version: 1.0.61
    type: VS Code extension
    displayName: Bracket Pair Colorizer
    title: Bracket Pair Colorizer
    description: Bracket Pair Colorizer
    icon: https://raw.githubusercontent.com/redhat-developer/codeready-workspaces/master/dependencies/che-plugin-registry/resources/images/default.svg?sanitize=true
    repository: https://github.com/CoenraadS/BracketPair
    category: Language
    firstPublicationDate: '2020-07-30'
    spec:                                                             1
      extensions:
      - "{{REPOSITORY}}/CoenraadS.bracket-pair-colorizer-1.0.61.vsix" 2
    latestUpdateDate: "2020-07-30"

    1
    This extension requires a basic Node.js runtime, so it is not necessary to add a custom runtime image in plugin.yaml.
    2
    {{REPOSITORY}} is a macro for a pre-commit hook.
  7. Define a memory limit and volumes:

    spec:
      containers:
        - image: "quay.io/eclipse/che-sidecar-java:8-0cfbacb"
          name: vscode-java
          memoryLimit: "1500Mi"
          volumes:
          - mountPath: "/home/theia/.m2"
            name: m2
  8. Create a devfile.yaml that references the plugin.yaml file:

    apiVersion: 1.0.0
    metadata:
      generateName: java-maven-
    projects:
      -
        name: console-java-simple
        source:
          type: git
          location: "https://github.com/che-samples/console-java-simple.git"
          branch: java1.11
    components:
      -
        type: chePlugin
        id: redhat/java11/latest
      -
        type: chePlugin 1
        reference: "{{REPOSITORY}}/plugin.yaml"
      -
        type: dockerimage
        alias: maven
        image: quay.io/eclipse/che-java11-maven:nightly
        memoryLimit: 512Mi
        mountSources: true
        volumes:
          - name: m2
            containerPath: /home/user/.m2
    commands:
      -
        name: maven build
        actions:
          -
            type: exec
            component: maven
            command: "mvn clean install"
            workdir: ${CHE_PROJECTS_ROOT}/console-java-simple
      -
        name: maven build and run
        actions:
          -
            type: exec
            component: maven
            command: "mvn clean install && java -jar ./target/*.jar"
            workdir: ${CHE_PROJECTS_ROOT}/console-java-simple
    1
    Any other devfile definition is also accepted. The important information in this devfile are the lines defining this external component. It means that an external reference defines the plug-in (instead of an ID pointing to a definition in the default plug-in registry).
  9. Verify there are 4 files in the current Git directory:

    $ ls -la
    .git
    CoenraadS.bracket-pair-colorizer-1.0.61.vsix
    README.md
    devfile.yaml
    plugin.yaml
  10. Before committing the files, add a pre-commit hook to update the {{REPOSITORY}} variable to the public external raw gist link:

    1. Create a .git/hooks/pre-commit file with this content:

      #!/bin/sh
      
      # get modified files
      FILES=$(git diff --cached --name-only --diff-filter=ACMR "*.yaml" | sed 's| |\\ |g')
      
      # exit fast if no files found
      [ -z "$FILES" ] && exit 0
      
      # grab remote origin
      origin=$(git config --get remote.origin.url)
      url="${origin}/raw"
      
      # iterate on files and add the good prefix pattern
      for FILE in ${FILES}; do
       sed -e "s#{{REPOSITORY}}#${url}#g" "${FILE}" > "${FILE}.back"
       mv "${FILE}.back" "${FILE}"
      done
      
      # Add back to staging
      echo "$FILES" | xargs git add
      
      exit 0

      The hook replaces the {{REPOSITORY}} macro and adds the external raw link to the gist.

    2. Make the script executable:

      $ chmod u+x .git/hooks/pre-commit
  11. Commit and push the files:

    # Add files
    $ git add *
    
    # Commit
    $ git commit -m "Initial Commit for the test of our extension"
    [master 98dd370] Initial Commit for the test of our extension
     3 files changed, 61 insertions(+)
     create mode 100644 CoenraadS.bracket-pair-colorizer-1.0.61.vsix
     create mode 100644 devfile.yaml
     create mode 100644 plugin.yaml
    
    # and push the files to the main branch
    $ git push origin
  12. Visit the gist website and verify that all links have the correct public URL and do not contain any {{REPOSITORY}} variables. To reach the devfile:

    $ echo "$(git config --get remote.origin.url)/raw/devfile.yaml"

    or:

    $ echo "https://<che-server>/f?url=$(git config --get remote.origin.url)/raw/devfile.yaml"

4.4.2. Verifying the VS Code extension API compatibility level

Che-Theia does not fully support the VS Code extensions API. The vscode-theia-comparator is used to analyze the compatibility between the Che-Theia plug-in API and the VS Code extension API. This tool runs nightly, and the results are published on the vscode-theia-comparator GitHub page.

Prerequisites

Procedure

To run the vscode-theia comparator manually:

  1. Clone the vscode-theia-comparator repository, and build it using the yarn command.
  2. Set the GITHUB_TOKEN environment variable to your token.
  3. Execute the yarn run generate command to generate a report.
  4. Open the out/status.html file to view the report.

4.5. Using alternative IDEs in CodeReady Workspaces

Extending Red Hat CodeReady Workspaces developer workspaces using different IDEs (integrated development environments) enables:

  • Re-purposing the environment for different use cases.
  • Providing a dedicated custom IDE for specific tools.
  • Providing different perspectives for individual users or groups of users.

Red Hat CodeReady Workspaces provides a default web IDE to be used with the developer workspaces. This IDE is completely decoupled. You can bring your own custom IDE for Red Hat CodeReady Workspaces:

Bringing custom IDE built from Eclipse Theia

  • Creating your own custom IDE based on Eclipse Theia.
  • Adding CodeReady Workspaces-specific tools to your custom IDE.
  • Packaging your custom IDE into the available editors for CodeReady Workspaces.

Bringing your completely different web IDE into CodeReady Workspaces

  • Packaging your custom IDE into the available editors for CodeReady Workspaces.

4.6. Support for JetBrains IDEs

This section contains information about supported JetBrains IDEs that can be used in Red Hat CodeReady Workspaces workspaces.

Red Hat CodeReady Workspaces supports running a workspace with the following list of JetBrains IDEs:

  • IntelliJ Idea Community Edition
  • IntelliJ Idea Ultimate Edition
  • WebStorm

List of JetBrains IDEs that are planned to be supported:

  • GoLand
  • PhpStorm
  • PyCharm Professional Edition
  • PyCharm Community Edition
Note

The version of supported JetBrains products should is 2018.1 or higher.

The following sections describe how to create an image with a specific IDE and workspace based on the built image:

4.6.1. Using IntelliJ Idea Community Edition

Procedure

  1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.
  2. Build IntelliJ Idea Community Edition by calling the following command inside the repository folder:

    $ podman build -t idea-ic --build-arg PRODUCT_NAME=ideaIC .

    This command builds an image with a 2020.2.3 version by default.

  3. Tag and push the built image to a user repository:

    $ podman tag idea-ic:latest <username>/idea-ic:latest
    $ podman push <username>/idea-ic:latest
  4. Use this image as the CodeReady Workspaces editor. To achive this, create two YAML configuration files:

    • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

      metadata:
        name: che-ideaic
      components:
        - type: cheEditor
          reference: '<URL to the meta.yaml>'
          alias: ideaic-editor
      apiVersion: 1.0.0
    • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

      apiVersion: v2
      publisher: <username>
      name: ideaic-NOVNC
      version: 2020.2.3
      type: Che Editor
      displayName:  IntelliJ IDEA Community Edition
      title:  IntelliJ IDEA Community Edition (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
      description:  IntelliJ IDEA Community Edition running on the Web with noVNC
      icon: https://resources.jetbrains.com/storage/products/intellij-idea/img/meta/intellij-idea_logo_300x300.png
      category: Editor
      repository: https://github.com/che-incubator/che-editor-intellij-community
      firstPublicationDate: "2020-10-27"
      spec:
        endpoints:
         - name: "intellij"
           public: true
           targetPort: 8080
           attributes:
             protocol: http
             type: ide
             path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
        containers:
         - name: ideaic-novnc
           image: "<username>/idea-ic:latest"
           mountSources: true
           volumes:
            - mountPath: "/JetBrains/ideaIC"
              name: ideaic-configuration
           ports:
            - exposedPort: 8080
           memoryLimit: "2048M"

4.6.2. Using IntelliJ Idea Ultimate Edition

Procedure

  1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.
  2. Build IntelliJ Idea Ultimate Edition by calling the following command inside the repository folder:

    $ podman build -t idea-iu --build-arg PRODUCT_NAME=ideaIU .

    This command builds an image with a 2020.2.3 version by default.

  3. Tag and push the built image to a user repository:

    $ podman tag idea-iu:latest <username>/idea-iu:latest
    $ podman push <username>/idea-iu:latest
  4. Provision the activation code for offline use to be able to use WebStorm with a registered license. See section Section 4.6.4, “Provisioning JetBrains activation code for offline use”.
  5. Create a workspace with the following workspace.yaml and meta.yaml files:

    • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

      metadata:
        name: che-ideaiu
      components:
        - type: cheEditor
          reference: '<URL to the meta.yaml>'
          alias: ideaiu-editor
          automountWorkspaceSecrets: true
      apiVersion: 1.0.0
      Note

      In the current workspace definition, there is a new property: automountWorkspaceSecrets: true. This property instructs Red Hat CodeReady Workspaces to provision secrets into a specific component. In this case, it provisions it into the CodeReady Workspaces editor based on IntelliJ Idea Ultimate Edition. This parameter is mandatory to successfully register the IDE with an activation code for offline use.

    • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

      apiVersion: v2
      publisher: <username>
      name: ideaIU-NOVNC
      version: 2020.2.3
      type: Che Editor
      displayName:  IntelliJ IDEA Ultimate Edition
      title:  IntelliJ IDEA Ultimate Edition (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
      description:  IntelliJ IDEA Ultimate Edition running on the Web with noVNC
      icon: https://resources.jetbrains.com/storage/products/intellij-idea/img/meta/intellij-idea_logo_300x300.png
      category: Editor
      repository: https://github.com/che-incubator/che-editor-intellij-community
      firstPublicationDate: "2020-10-27"
      spec:
        endpoints:
         -  name: "intellij"
            public: true
            targetPort: 8080
            attributes:
              protocol: http
              type: ide
              path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
        containers:
         - name: ideaiu-novnc
           image: "<username>/idea-iu:latest"
           mountSources: true
           volumes:
               - mountPath: "/JetBrains/ideaIU"
                 name: ideaiu-configuration
           ports:
               - exposedPort: 8080
           memoryLimit: "2048M"

4.6.3. Using WebStorm

Procedure

  1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.
  2. Build the image:

    $ podman build -t webstorm --build-arg PRODUCT_NAME=WebStorm .

    This command builds an image with a 2020.2.3 version by default.

  3. Tag and push the built image to a user repository:

    $ podman tag webstorm:latest <username>/webstorm:latest
    $ podman push <username>/webstorm:latest
  4. Provision the activation code for offline use to be able to use WebStorm with a registered license. See section Section 4.6.4, “Provisioning JetBrains activation code for offline use”.
  5. Create a workspace with the following workspace.yaml and meta.yaml files:

    • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

      metadata:
        name: che-webstorm
      components:
        - type: cheEditor
          reference: '<URL to meta.yaml>'
          alias: webstorm-editor
          automountWorkspaceSecrets: true
      apiVersion: 1.0.0
      Note

      In the current workspace definition, there is a new property: automountWorkspaceSecrets: true. This property instructs Red Hat CodeReady Workspaces to provision secrets into a specific component. In this case, it provisions it into the CodeReady Workspaces editor based on IntelliJ Idea Ultimate Edition. This parameter is mandatory to successfully register the IDE with an activation code for offline use.

    • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

      apiVersion: v2
      publisher: <username>
      name: webstorm-NOVNC
      version: 2020.2.3
      type: Che Editor
      displayName:  WebStorm
      title:  WebStorm (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
      description:  WebStorm running on the Web with noVNC
      icon: https://resources.jetbrains.com/storage/products/webstorm/img/meta/webstorm_logo_300x300.png
      category: Editor
      repository: https://github.com/che-incubator/che-editor-intellij-community
      firstPublicationDate: "2020-10-27"
      spec:
        endpoints:
         - name: "intellij"
           public: true
           targetPort: 8080
           attributes:
             protocol: http
             type: ide
             path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
        containers:
         - name: webstorm-novnc
           image: "<username>/webstorm:latest"
           mountSources: true
           volumes:
            - mountPath: "/JetBrains/WebStorm"
              name: webstorm-configuration
           ports:
            - exposedPort: 8080
           memoryLimit: "2048M"

4.6.4. Provisioning JetBrains activation code for offline use

An activation code for offline use is a file with a license code that can be retrieved from the license management section of your JetBrains account for the license that is assigned to you. When you purchase a personal subscription or are assigned a commercial subscription by your organization, you receive an email prompting you to create a JetBrains account that becomes connected with the license.

Note

When using an activation code to activate a product, you need to generate a new activation code and apply it to your product each time the subscription is renewed.

Prerequisites

  • JetBrains account
  • Personal or organization subscription

Procedure

  1. Retrieve the activation code from the JetBrains account:

    jetbrains account

    JetBrains provides a ZIP archive with two types of the activation code. Use the <License ID> - for 2018.1 or later.txt file:

    activation code
  2. Provision the activation code for offline use with Che. This procedure is performed through the OpenShift Secrets.
  3. Create a OpenShift Secret to instruct CodeReady Workspaces to mount the activation code into a container based on JetBrains specific product:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret name> 1
      labels:
        app.kubernetes.io/component: workspace-secret
        app.kubernetes.io/part-of: che.eclipse.org
      annotations:
        che.eclipse.org/automount-workspace-secret: 'false'
        che.eclipse.org/mount-path: /tmp/
        che.eclipse.org/mount-as: file
    data:
      <product name (ideaIU or WebStorm)>.key: <base64-encoded data content> 2
    1
    <secret name> – The section that specifies the secret name. It may have a different name, for example, ideaiu-offline-activation-code. Provide the secret name in lowercase.
    2
    Product name and activation code:

Use the automount-workspace-secret option set to false to disable the mounting process until it is explicitly requested in a devfile component using the automountWorkspaceSecrets:true property. See the workspace.yaml example file above. This is the default behavior to avoid mounting the activation code into every container except specific ones that have to work with it.

As a result, in the Che Editor, the file with the activation code for offline use is mounted to the /tmp/ideaIU.key or /tmp/WebStorm.key path (or similar - based on the type of the build).

IntelliJ Idea Community Edition does not require this procedure. This has to be done for JetBrains products that need to be registered.

4.6.4.1. JetBrains product-name mapping

This section provides mapping used internally between JetBrains products and the product name during image build.

JetBrains ProductPRODUCT_NAME

IntelliJ Idea Community Edition

ideaIC

IntelliJ Idea Ultimate Edition

ideaIU

WebStorm

WebStorm

4.7. Adding tools to CodeReady Workspaces after creating a workspace

When installed in a workspace, CodeReady Workspaces plug-ins bring new capabilities to CodeReady Workspaces. Plug-ins consist of a Che-Theia plug-in, metadata, and a hosting container. These plug-ins may provide the following capabilities:

  • Integrating with other systems, including OpenShift.
  • Automating some developer tasks, such as formatting, refactoring, and running automated tests.
  • Communicating with multiple databases directly from the IDE.
  • Enhanced code navigation, auto-completion and error highlighting.

This chapter provides basic information about installing, enabling, and using CodeReady Workspaces plug-ins in workspaces.

4.7.1. Additional tools in the CodeReady Workspaces workspace

CodeReady Workspaces plug-ins are extensions to the Che-Theia IDE that come bundled with container images. These images contain the native prerequisites of their respective extensions. For example, the oc command-line tool is bundled with a command to install it, which ensures the proper functionality of the OpenShift Connector plug-in, all available in the dedicated image.

Plug-ins can also include metadata to define a description, categorization tags, and an icon. CodeReady Workspaces provides a registry of plug-ins available for installation into the user’s workspace.

The Che-Theia IDE is generally compatible with the VS Code extensions API and VS Code extensions are automatically compatible with Che-Theia. These extensions are possible to package as CodeReady Workspaces plug-ins by combining them with their dependencies. By default, CodeReady Workspaces includes a plug-in registry containing common plug-ins.

Adding a plug-in

  • Using the Dashboard:

    • Add a plug-in from the plug-in registry using the Plugins tab in the Workspace details page.
    • Add a plug-in directly into a devfile using the Devfile tab.

      The devfile can also further the plug-in configuration, such as defining memory or CPU usage.

  • Using the Che-Theia IDE:

    • By pressing Ctrl+Shift+J or by navigating to View → Plugins.

4.7.2. Adding a language support plug-in to a CodeReady Workspaces workspace

This procedure describes adding a tool to an existing workspace by enabling a dedicated plug-in from the Dashboard.

To add tools that are available as plug-ins into a CodeReady Workspaces workspace, use one of the following methods:

This procedure uses the Language Support for Java plug-in as an example.

Prerequisites

Procedure

To add the plug-in from the Plug-in registry to an existing CodeReady Workspaces workspace, use one of the following methods:

  • Installing the plug-in from the Plugins tab.

    1. Navigate to the Plugins tab. The list of available plug-ins is displayed.
    2. Enable the desired plug-in, for example, the Language Support for Java 11, by using the Enable slide-toggle. This will add the plug-in’s ID to the workspace’s devfile, enabling the plug-in.
    3. On the bottom right side of the screen, save the changes by clicking the Save button. After changes are saved, the workspace can be restarted and will include the new plug-in.
  • Installing the plug-in by adding content to the devfile.

    1. Navigate to the Devfile tab. The devfile YAML is displayed.
    2. Locate the components section of the devfile and add the following lines to add the Java language plugin with Java 8 to the workspace:

       - id: redhat/java8/latest
         type: chePlugin

      An example of the final result:

      components:
       - id: redhat/php/latest
         memoryLimit: 1Gi
         type: chePlugin
       - id: redhat/php-debugger/latest
         memoryLimit: 256Mi
         type: chePlugin
       - mountSources: true
         endpoints:
           - name: 8080/tcp
             port: 8080
         memoryLimit: 512Mi
         type: dockerimage
         volumes:
           - name: composer
             containerPath: {prod-home}/.composer
           - name: symfony
             containerPath: {prod-home}/.symfony
         alias: php
         image: 'quay.io/eclipse/che-php-7:nightly'
       - id: redhat/java8/latest
         type: chePlugin
    3. On the bottom right side of the screen, save the changes by clicking the Save button. After changes are saved, the workspace can be restarted and will include the new plug-in.

Additional resources