Eclipse Che – Red Hat Developer BlogInsights and news on Red Hat Developer tools, platforms and more
2019-05-25T07:00:26Z https://developers.redhat.com/blog/feed/atom/WordPressDoug Tidwellhttp://dougtidwell.comhttps://developers.redhat.com/blog/?p=5706572019-03-11T12:36:00Z2019-03-11T07:05:23ZThis video is a brief overview of Eclipse Che presented by CodeReady Workspaces Product Manager Stévan Le Meur. The tour starts in a git repo that contains a link to a Che factory. Opening that factory loads the code from the git repo and sets up a complete development environment. From there, Stévan covers how to build, […]

]]>This video is a brief overview of Eclipse Che presented by CodeReady Workspaces Product Manager Stévan Le Meur. The tour starts in a git repo that contains a link to a Che factory. Opening that factory loads the code from the git repo and sets up a complete development environment. From there, Stévan covers how to build, run, and debug the code within Che.

The tour ends with a pull request to the original repo, showing how the comment sent to git includes a factory link to the modified code, making it easy for anyone evaluating the PR to see exactly how the updated code works.

]]>0Laurent Broudouxhttps://developers.redhat.com/blog/?p=5541172019-02-21T17:16:10Z2019-01-28T13:00:21ZThis is the second half of my series covering how to use Red Hat CodeReady Workspaces to develop a Java Enterprise Edition (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP) in the cloud on Red Hat OpenShift/Kubernetes. In the first part, we saw how to: Bring your own tools by extending […]

Create your workspace using your stack and embedding your JEE project located on a Git repository

For this second part, we’ll start configuring the workspace by adding some helpful settings and commands for building and running a JBoss EAP project. We’ll then see how to use the local JBoss EAP instance for deploying and debugging our application. Finally, we’ll create a factory so that we’ll be able to share our work and propose an on-demand configured development environment for anyone that needs to collaborate on our project.

Configuring your JBoss EAP workspace

In the previous article, we ended up with a workspace that was configured for Java but with some missing dependencies. An extra step is usually necessary: indicate that you’re dealing with a Maven project. This has to be done only once by the user that set up the workspace. For that, go to Project > Update Project Configuration and enable Maven under the JAVA section. Once that is done, an additional External Libraries item appears in your project tree. You can now open Java files and play around with code navigation, Java completion, and so on.

You should now be able to launch your first build command. Open the Commands Palette using Run > Commands Palette or the Shift+F10 shortcut. You’ll see the build command was defined when you created the workspace and you may double-click it to run it.

After a few seconds, you’ll see the successful build in the build command’s dedicated console.

Nice! You can now start modifying code and do some refactoring. We’re able to edit code, compile it, and package it, but let’s see how to test it locally within our JBoss EAP instance.

Adding some JBoss EAP commands

Let’s start by adding a new command for starting the JBoss EAP instance that is included within our stack image. Looking just above the project tree view, you’ll find an icon on the right that allows you to open the commands management view. You’ll see that commands are categorized into BUILD, TEST, RUN, DEBUG, DEPLOY, and COMMON goals. In the RUN section, create a new Custom command that you’ll call start-eap and add the command below:

You can now launch this command through the Command Palette or through the Run blue arrow on the menu bar. The command is executed in its own console and you should see output like the following indicating that your JBoss EAP 7.1 instance is up and running.

Now let’s deploy our application to the running instance. For that, let’s create a new command within the DEPLOY section and call it copy-war. Add the command below and execute it.

This enables the previously built WAR archive to be deployed to our JBoss EAP instance’s deployments folder. The instance should now hot-deploy it in a few seconds. You may now want to check your application and play with it. Just right of the command console, click the + button and choose Servers. This will open a new view displaying the URL corresponding to the different servers attached to your workspaces. Remember the eap server we declared in the stack configuration? This information is used by Red Hat CodeReady Workspaces to create a new OpenShift route that allows you to access your deployed application!

Just copy and paste the URL into your browser and you should see our test application live.

For now, we just have created simple commands deploying a packaged WAR but you can also call some commands allowing you to work using an exploded directory structure and hot-reload of JSP and static resources. For example, I use the following build-dev command for initializing a directory structure within the deployment folder of the JBoss EAP instance:

Debugging

Red Hat CodeReady Workspace tooling can also be used for debugging your application. In order to do that, create a new command as usual within the DEBUG section. Let’s call it start-eap-debug and just put there the following command, including the debug flag and the port 8000 we have used within our stack definition:

Now start the JBoss EAP instance using the debug mode. Before starting it up again, you may want to stop the running instance: you can achieve that by looking for the start-eap running process in the top EXEC menu bar and clicking the blue square. Your instance is now launched in debug mode and you have to launch a debug session within the IDE. Before doing so, remember that the Edit Debug Configurations item in the Run menu lets you configure a connection to a remote JBoss EAP instance using port 8000, as shown below.

You can now start a debug session through the Run > Debug > Remote EAP menu item. The IDE connects to localhost:8000 and switches to the debug perspective. You can now open some Java class like /src/main/com/openshift/service/DemoResource.java file. Click on line 44 to place a breakpoint. Now go to the browser tab hosting your app and click the Log Info button; you should see the debug session starting in the workspace and filling up the Frames and Variables panels.

Sharing your work with a factory

Setting up everything was not that hard but it takes a little time and can be error-prone. Red Hat CodeReady Workspaces offers the concept of a factory in order to be able to reproduce and duplicate a workspace configuration. Using factories, you can easily onboard new collaborators for your project by making everything available with a single click!

Let’s create a factory for our workspace. From the Red Hat CodeReady Workspace dashboard, choose the Factories menu item on the left vertical menu, and then give your factory a name and select the Workspace you want to use as a basis. Choose CREATE and then explore the factory properties in the detail screen:

The most important attributes of a factory are its URLs, which can be used for launching a new workspace embedding all the configuration and commands we added to the original workspace. A URL may be combined with nice badges to offer instant access for any README or wiki page.

Just copy and paste one of the URLs into a browser tab or click a badge and you’ll see this nice crane animation building your own workspace on demand, allowing you to quickly starting collaboration on a new project.

Now that your collaborator’s workspace is up and running, she can start coding and easily contributing pull requests to your original source code repository. But I’ll leave that topic for a later article.

Get started!

We have seen through this tour how Red Hat CodeReady Workspaces allow you to configure a development environment and easily replicate and distribute it among your organization. The embedded cloud/browser-based IDE provides everything you need to start quickly collaborating on projects while providing you security through centralization of source code and authentication of access. Red Hat CodeReady Workspaces gives you greater security and faster onboarding, and it ensures your code works on all your developers’ machines too.

Best of all, it’s easy to sign up for the beta. Visit the product page to get the code and everything you need to know about the product.

]]>0Florent Benoithttps://developers.redhat.com/blog/?p=5549472019-02-21T17:37:08Z2019-01-22T13:00:06ZRecently the Eclipse Che community has been working to make Eclipse Theia the default web IDE for Eclipse Che 7. We’ve added a plugin model to Eclipse Theia that is compatible with Visual Studio Code (VS Code) extensions. Che 7 users will eventually be able to take advantage of extensions that have been written for […]

]]>Recently the Eclipse Che community has been working to make Eclipse Theia the default web IDE for Eclipse Che 7. We’ve added a plugin model to Eclipse Theia that is compatible with Visual Studio Code (VS Code) extensions. Che 7 users will eventually be able to take advantage of extensions that have been written for VS Code in their cloud-based developer workspaces. It’s worth pointing out the popularity of VS Code extensions. Red Hat has contributed extensions covering Java, XML, YAML, OpenShift, and dependency analytics. The Java extension provided by Red Hat has been downloaded over 10 million times!

If you aren’t familiar with Eclipse Theia, Che 6 and earlier used a GWT-based IDE. While it is possible to develop and use plugins in that environment, it is cumbersome. Coming from tools like VS Code, developers expect to be able to customize and extend their workspaces at runtime. Eclipse Theia is an extensible open-source framework to develop multi-language IDEs using state-of-the-art web technologies. Moving to Theia as the default IDE for Che 7 provides a foundation to enrich the developer workspaces in Che. See the series of articles by Stevan LeMeur for more information about what’s coming in Che 7.

This article explains why we decided to add the new plugin model to Eclipse Theia and the benefits for Eclipse Che 7 developer workspaces. I also cover how the new plugin model differs from the existing Theia extension model.

Drawbacks of the previous GWT-based IDE

There were a number drawbacks with the GWT-based IDE used in Che 6 and earlier. Adding a plugin requires stopping, recompiling, and reloading the whole IDE. Experiments were tried to dynamically load JavaScript plugins using JS-Interop. The GWT-based IDE provided a low-level API with the advantage that you could change anything, but the disadvantage is any plugin could break anything. Also, it is difficult to understand all of the entry points for the current API.

In the end, we also had to take into consideration that many people dislike GWT and feel it is a technology of the past.

Requirements for extensibility

Based on our experiences, a lot of people wanted to improve the extensibility model for the next major version of Eclipse Che. For Che 7, we came up with the following requirements:

It should be easy to load plugins at runtime and it should not involve any extra compilation or installation steps. Therefore, plugins should be already compiled. The IDE only needs to load the code.

A poorly written plugin should not be able to break the whole IDE. If the user loads a plugin that has an error, the user should still be able to continue to use the current IDE.

In Eclipse Che, we wanted to guarantee that a plugin can’t block the main functions of the IDE like opening a file or typing. The user should be able to identify whether a problem is caused by a plugin or is an issue with the core product itself. If two plugins have a requirement for different/conflicting versions of a dependency, that should be allowed and shouldn’t cause problems. Each plugin should get the specific version of the dependency it requires.

Drawbacks of the Theia extension model

Eclipse Theia was chosen as the alternative IDE for Che 7 and beyond. Theia has an extension model, which we’ll refer to as Theia extensions. The problem with the existing extension model was that it was mainly designed to develop custom IDEs. As a result, it has the similar drawbacks when developers try to customize their development workspace at runtime the way they can in VS Code:

With Eclipse Theia extensions, when a new extension is added, the whole IDE is recompiled. If there are errors introduced by the extension, you may break the whole IDE. So after adding an extension, you could open a Che workspace and wind up with a blank page due to a compilation error instead of the IDE.

Extensions are retrieved from the npmjs repository. While this can be nice because npmjs has tons of libraries, when you install an extension it will download all dependencies again and again. If you’ve many dependencies, it may break. Additionally, you aren’t able to add a local repository for private extensions.

Theia extensions allow extension writers to customize the whole IDE. However similar to the GWT-based IDE, any extension can easily break the whole IDE. Diagnosis can be difficult.

The complexity of the extension model is too challenging for new developers. The Theia extension model has a lot of power that is great for advanced users; however, if you want to write your first extension, you need to master inverify and dependency injection. You also need to know which class is doing what and which interface you need to implement.

Clearly, Theia’s extension model was not matching up with our requirements for extensibility.

Introducing Theia plugins

At Red Hat, to meet our extensibility requirements we came up with the Theia Plugin Model. The key aspects are:

Plugins can be loaded at any time at the runtime without having to restart/refresh the IDE.

Eclipse Theia plugins are self-contained and packaged into .theia files. They contain all the runtime code for the plugins. There is no need to download anything else at startup.

Theia plugins have a simple API that is easy to learn. You can use a dependency injection framework, but you don’t have to. It’s your choice. The model is as simple as importing only one namespace, @theia/plugin (through the npmjs package @theia/plugin), and you can get what you need from this entry point with code completion on this object. You implement the lifecycle of your plugin by implementing the start and stop functions.

Theia plugin protocol

Theia plugins use a protocol, which means you can run plugins anywhere! Some plugins can run in worker threads of the browser (they are called front-end plugins) or they can run on the server side in separate processes (back-end plugins). It’s easy to handle other kinds of namespace, including VS Code extensions.

Hear’s an architecture diagram:

The model is backward-compliant. The plugin model is provided through a TypeScript declaration file. The plugin code could be completely rewritten or Theia classes could be refactored; however, the model will remain unchanged.

The API is a high-level API designed so that plugins can’t break the IDE. You might not be able to change everything you could think of in a plugin, but there are nearly unlimited possibilities to provide useful functionality for developers.

Container-ready

Eclipse Che is using containers for developer tools. Theia plugins are written in TypeScript/Javascript and that works well. But sometimes, plugins writers need some dependencies that are not only pure npmjs dependencies. For example, if developers write a language server for Java, this plugin will probably require Java. So it might imply that the container that runs Eclipse Theia should have Java already installed on it.

This is why in Eclipse Che, it’s possible to run each Eclipse Theia plugin in its own container. This allows a plugin to use any system dependency it needs in its own container.

By default, all plugins are executed as a separate process in the Theia container:

VS Code extensions

The Eclipse Theia plugin protocol has been implemented in an extensible fashion and conforms to the VS Code API. This will allow some VS Code extensions to run inside of Theia. The API support will determine which extensions are compatible.

For example, it is currently possible to use the SonarLint VS Code extension from VS Code marketplace:

After loading the SonarLint VS Code extension at runtime, you can see the immediate results in a JavaScript source file:

Here is the plugins view in Eclipse Theia after loading the VS Code extension:

]]>0Laurent Broudouxhttps://developers.redhat.com/blog/?p=5536772019-02-21T17:13:18Z2019-01-21T13:00:07ZIt has been just one month since the announcement of the release of Red Hat CodeReady Workspaces 1.0.0 Beta. Because the cloud/browser-based IDE may be full of promises, developers are usually suspicious, considering them as toys for occasional coders but not suitable for software craftsmen. But you’ll quickly see that Red Hat’s offering can be a […]

]]>It has been just one month since the announcement of the release of Red Hat CodeReady Workspaces 1.0.0 Beta. Because the cloud/browser-based IDE may be full of promises, developers are usually suspicious, considering them as toys for occasional coders but not suitable for software craftsmen. But you’ll quickly see that Red Hat’s offering can be a good companion for building tailor-made environments.

The goal of this two-part series is to give a walk-through of using Red Hat CodeReady Workspaces to develop a Java EE (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP). I’ll give you details on how to bring your own tools, configure your workspace with helpful commands for JBoss EAP, and share everything so you can easily onboard new developers.

Red Hat CodeReady Workspaces

Secured access to the development environment with source code that may remain on the central server, not the developer’s laptop

Extensible configuration allowing you to bring your own tools and reuse the runtimes you’ll use in production

A rich, browser-based development experience including auto-completion, navigation, debuggers, and easy sharing through the factory concept

The entire product runs on a Red Hat OpenShift cluster (on-premises or in the cloud), so there’s nothing to install on your machine. The installation instructions give details on how to set up everything on your OpenShift cluster; installation is done through an Ansible PlayBook Bundle running on the cluster Ansible Service Broker. Although it makes extensive use of containers technology for installation, defining your stacks, and configuring your workspaces, it is not exclusively dedicated to the development of applications running as containers. That’s what I’m trying to demonstrate throughout this post.

Defining your custom stack

A Red Hat CodeReady Workspaces stack is the basic building block for workspaces: it includes everything you may need for compiling, testing, debugging, or packaging your app. Even though the Red Hat CodeReady Workspaces installation comes with default stacks for many technologies (Java, JBoss EAP, Spring Boot, NodeJS, Python, and so on), extending them and creating your own stack is a common practice. Stacks are based on one or many container images and as such, providing stacks is basically a matter of writing Dockerfiles and building images.

Some common use cases, imagine your organization uses self-signed certificates to access infrastructure or you have started working with containerized apps on OpenShift and find it convenient to also use the oc or the odo command-line tools. You may have to extend the default stacks-java:1.0.0.Beta1 provided by Red Hat—which already includes OpenJDK, JBoss EAP, and Maven—in order to add your custom CA certificate and the tools you need:

Once you have produced this Dockerfile and put your ca.crt file in same directory, you just have to build your image and push it into a container images registry that is made available to your OpenShift cluster.

Above, I’ve put my image on docker.io and you may easily reuse mine for a quick test. Then, we may start building a custom Red Hat CodeReady Workspace stack from the administration console.

Click on the Stacks left menu and review the default stack. Then you just have to click the Add Stack button to make a modal dialog appear, asking you for a Recipe. For this article, we are going to create a single container stack, so just select the DOCKERIMAGE thumbnail and enter the name of the Docker image we previously created: docker.io/lbroudoux/stacks-jaba:1.0.0.Beta2.

After having verified that the image exists, we navigate to the form allowing you to configure your stack. So start by assigning it a Name and a Description.

Scroll down to the Machines section. Here we have a single Machine and we decide to name it dev-machine. We can check that our machine will be based on the container image we provide and we may also adjust the number of resources that will be dedicated to this machine. There’s more info on the machine here.

Scrolling down, we can check the Agents (or Installers) section. Agents allow you to activate specific features of the Eclipse Che IDE. Here, we’ll need the basic one for dealing with Java: being able to execute commands, opening a terminal, and interacting with the Workspace API. More info on installers is available here.

Below that is a very important part of the stack configuration where you may define the different Servers that will expose your machine. A servers definition allows you to declare the network ports that will be exposed by your workspace and that your developers will use for interacting and connecting to the app. In the case of our JBoss EAP development environment, we’ll declare two ports:

The next section is related to Commands. Here we’re going to add a single command for building the whole project using Maven. We’ll add some other commands during our first tests of a new workspace. Commands are used to build, debug your app and interact with your server. More info on commands is here.

Finally, you may end by adding a description for components embedded in your stack. These descriptions are pure informational components and help with tags to organize your stack within the repository.

Once you have finished editing these last sections, you may now save your stack for later use through JBoss EAP workspaces. You can also check that everything you’ve done is exportable as JSON and can be versioned and saved into a Git repository. Just click the Show button within the Raw Configuration section. Everything we’ve seen and done so far can be found in my github.com/lbroudoux/codeready-workspaces repository.

Starting a JBoss EAP workspace

Now that we have a stack to build on, we may create a new workspace. So from the dashboard or the Workspaces page of Red Hat CodeReady Workspaces, just click the Add Workspace button. Creating a workspace starts by giving it a Name and picking the stack we previously created, as shown below.

Workspaces are there for working on projects, so within the Projects section, be sure to add a new project. You can, for example, refer to one located on GitHub. I used github.com/lbroudoux/openshift-tasks, which is a JEE/JBoss EAP app I’ve used for demonstrating deployment on OpenShift, even though in our case, we’ll deploy the application to a regular, not containerized, JBoss EAP instance.

Leave untouched the other options and then create and run your workspace. In a few minutes, you should have a working IDE where a project has been cloned from GitHub and all the dev tools such as Java Language Server have started up into the dev-machine console.

Next steps

In this first part of the series, we have seen how to extend the Red Hat CodeReady Workspaces base image to include extra tooling and certificates. We have registered everything as a custom stack within the administration portal. Finally, we started a new workspace containing everything we need to code, compile, deploy, debug, and package our JEE/JBoss EAP application.

]]>0Stevan LeMeurhttps://developers.redhat.com/blog/?p=5510672018-12-21T17:53:02Z2018-12-21T17:53:02ZEclipse Che 7 is an enterprise-grade IDE that is designed to solve many of the challenges faced by enterprise development teams. In my previous articles, I covered the main focus areas for Eclipse Che 7, the new plugin model, and kube-native developer workspaces. This article explains security and management of Eclipse Che 7 in enterprise deployment scenarios […]

Enterprise Grade Cloud IDE

Eclipse Che has gained a great deal of interest in large enterprises that are moving to containers and want to standardize the developer workspace and remove intellectual property (source code) from hard-to-secure laptops. There are a number of features needed in order to make Che a simple-to-manage tool for these large and often private environments. Organizations want to secure workspaces, deploy them on new infrastructure, and make it easier for teams to collaborate while maintaining developer autonomy.

For those reasons, we are working on a number of different facets to make Eclipse Che easier to run and simpler to administer and manage.

Eclipse Che 7 — timing?

There is A LOT that is coming with Eclipse Che 7. We spent a lot of time redefining the project’s foundations for the future, making it more enjoyable to use, easier to adopt by large enterprise, and able to support its community growth.

We are all very excited about this new version. In the following weeks, you’ll be reading more about the new capabilities and how they have been built. Eclipse Con Europe was a great event where we were able to unveil a lot of the work we’ve been doing. Now it is time to share it with a broader audience.

It’s available today: when you create a new workspace from the latest Eclipse Che release, you can select Che 7 stacks. You can test it now, and you can post feedback or report bugs — those are always helpful and valuable !

Eclipse Che 7 early beta will be available in February with GA-level Che 7 planned for March.

]]>0Stevan LeMeurhttps://developers.redhat.com/blog/?p=5508172018-12-21T17:54:59Z2018-12-20T22:30:52ZWith a new workspaces model and full “dev-mode” for application runtimes—Eclipse Che the first kube-native IDE! In Part 1 of this series, I highlighted the main focus areas for Eclipse Che 7. Part 2 covered the new plugin model. This article explains the different changes that have been introduced for Che workspaces, in order to provide […]

]]>With a new workspaces model and full “dev-mode” for application runtimes—Eclipse Che the first kube-native IDE!

In Part 1 of this series, I highlighted the main focus areas for Eclipse Che 7. Part 2 covered the new plugin model. This article explains the different changes that have been introduced for Che workspaces, in order to provide full “dev-mode” capabilities on top of application runtimes by sidecaring developer tooling.

Kubernetes native IDE

This new version of Eclipse Che makes it the first Kubernetes native IDE.

Developers using Eclipse Che use containers directly in their developer workspaces. Che workspaces provide a “dev mode” layer on top of the containers used in production, adding intellisense and IDE toolings.

The work on Workspace.Next allows Che to use bare application definitions (a Docker image, a Composefile or a list of Kubernetes resources) without the need to patch them to inject the IDE services. With Workspace.Next, IDE toolings are microservices packaged in their own sidecar containers, bringing their own dependencies and keeping application’s containers untouched. The execution of IDE toolings is isolated from each other and from the application’s containers too. Each IDE tool now gets its own lifecycle, the ability for easy upgrading or switching, and coming soon its own scalability mechanism.

]]>0Stevan LeMeurhttps://developers.redhat.com/blog/?p=5499672018-12-21T18:11:26Z2018-12-19T13:00:55ZWith a new plugin model and compatibility with VSCode Extensions — Eclipse Che is on Fire! In my last blog post, we highlighted the main focus areas of Eclipse Che 7. This blog post provides a deep dive on the new plugin model of Eclipse Che 7. New Plugin Model Eclipse Che is a great platform to build […]

]]>With a new plugin model and compatibility with VSCode Extensions — Eclipse Che is on Fire! In my last blog post, we highlighted the main focus areas of Eclipse Che 7. This blog post provides a deep dive on the new plugin model of Eclipse Che 7.

New Plugin Model

Eclipse Che is a great platform to build cloud-native tools. For Eclipse Che to be successful in its mission, it requires a strong extensibility model with an enjoyable developer experience for contributors.

In the past, Eclipse Che’s extensibility was focused on white-labelling use cases. ISVs were able to customize Eclipse Che, building their own version by completely customizing it and distributing it to their own audiences. While that extensibility approach has been great for many partners, it has always been seen as complex, with a technology stack (especially GWT in the IDE) which resulted in a non-optimal developer experience. The lack of a dynamic extensibility also forced a Che Plugin to be packaged in a “Che assembly” in order to make it available to end users. There was no way to quickly build a plugin, package it so that it could be installed in a running Che and make it available without rebuilding all of Che.

To address these issues we’ll be phasing out the GWT-based IDE in favour of another open Eclipse Foundation IDE project: Eclipse Theia. As introduced earlier, Eclipse Theia is a framework to build web IDEs. It is built in TypeScript and will give contributors a more enjoyable experience with a programming model that is more flexible and easier to use, and makes it faster to deliver their new plugins.

Our main goal is to provide a dynamic plugin model. In Che, a user shouldn’t need to worry about the dependencies needed for the tools running in their workspace — they should just be available when needed. This means that a Che plugin provides its dependencies, its back-end services (which could be running in a sidecar container connected to the user’s workspace), and the IDE UI extension. By packaging all these elements together, the user’s impression is that Che “magically” provided language services and the developer tooling they need for their workspace.

VSCode Extensibility Compatibility

There is one more important aspect of the plugin model — we want to rationalize the effort for a contributor who is willing to build a plugin and distribute in to different developer communities and tools. For that purpose, we have introduced into Eclipse Theia plugins API to allow compatibility with the extension points from VS Code. As result, it becomes much easier to bring an existing plugin from VS Code onto Eclipse Che. The main difference is in the way the plugins are packaged. On Eclipse Che, the plugins are delivered with their own dependencies in their own container.

See the video on the SonarSource VSCode plugin:

In order to expose these plugins and make them consumable we will build a plugin marketplace. This will be open to the community, but also allow private Che installs behind firewalls to create their own in-house marketplace with only the plugins which are appropriate for their users. Today, the plugins are under a plugin registry on a github repository

Self Hosting

Building plugins for Che must also be a fun experience and the turnarounds must be as fast as possible in the developer innerloop (the time spent between introducing a change and seeing/debugging the result. We needed to improve that from our previous GWT-based IDE, so we built a complete Hosted Mode to allow Che contributors to build Che directly from Che. It provides the complete lifecycle — from creating a new plugin, to coding it and debugging it. The team that is building that new capability is already using this and they love it. They also feel more productive than in the past

See this video on plugin development for Eclipse Che:

Try Eclipse Che 7 Now!

Want to give a try to the new version of Eclipse Che 7? Try the following:

]]>0Stevan LeMeurhttps://developers.redhat.com/blog/?p=5494372018-12-21T17:58:34Z2018-12-18T13:00:13ZA better plugin model, a new IDE, and Kubenative Workspaces — Eclipse Che Is on Fire ! With this article, I am starting a series of articles highlighting the new capabilities which will be introduced with Eclipse Che 7. This article provides an overview of the areas of focus for Eclipse Che 7 as well as its new […]

With this article, I am starting a series of articles highlighting the new capabilities which will be introduced with Eclipse Che 7. This article provides an overview of the areas of focus for Eclipse Che 7 as well as its new IDE and ability to use different IDEs such as Jupyter.

Intro

What a year for Eclipse Che! Release after release, Eclipse Che gets better and better thanks to the engagement of the community and your feedback.

As an open source project, the core values of Eclipse Che are to:

Accelerate project and developer onboarding: As a zero-install development environment that runs in your browser, Eclipse Che makes it easy for someone to join your team and contribute to a project.

Remove inconsistencies between developer environments: No more: “but it works on my machine….” Your code works (or doesn’t) exactly the same way in everyone’s environment.

Provide built-in security and enterprise readiness: As Eclipse Che becomes a viable replacement for VDI solutions, it must be secure and it must support enterprise requirements such as role-based access control (RBAC) and the ability to remove all source code from developer machines.

At the beginning of 2018 we shipped Eclipse Che version 6.0. That was a major milestone which added capabilities needed for developer teams and enterprises who wanted benefits from shared and rationalized developer environments. You can read more in the release note from Eclipse Che 6.0.

A few months ago, we announced during CheConf 18.1 the beginning of a new journey and a new chapter for Eclipse Che version 7. Seeing the interest from enterprises already using Eclipse Che and from the community that is building cloud-native applications, we organized the Che roadmap into 4 main areas:

IDE.next: Updates to the editor to increase the joy of development.

Plugins: Features to drive further growth in the Che ecosystem.

Workspace.next: IDE tools running as microservices in containers to improve the fidelity between developer workspaces and production environments.

Enterprises: Features to support large scale use of Che.

IDE.Next

We have integrated Eclipse Theia into Che to replace the GWT based IDE. Eclipse Theia has the foundation required to help us to enrich Eclipse Che.

Here is a small video showing the new IDE:

Only a few capabilities are shown in this video and there are a lot more to come. The most exciting ones are:

Monaco based editor: blazing fast and responsive editor, codelens and much more

However, there is a substantial feature gap between Eclipse Theia and our current Che IDE. Most of this year has been spent adding needed features to Theia so that it can fully replace the current IDE. The Eclipse Che contributors have spent more than five years building web IDEs in the cloud. So when we decided to switch to Eclipse Theia, we naturally wanted to make good use of that experience to make the new IDE really substantial. And enterprise grade.

We’ve been working hard to bring:

Debug Adapter Protocol

Language Server Protocol

Commands

Preferences

Keybindings

Textmate Support

Security

In the following months, that new IDE will become the default IDE for your workspaces.

Different IDEs for different use cases

There is one more thing. Che will still provide a default web IDE for workspaces, but we also did important work in order to decouple the IDE so that it is possible to plug a different IDE into Che workspaces. There are a lot of cases where the default IDE will not cover the use cases of your audience, or you might have stakeholders who are using a dedicated tool that covers their needs instead of using an IDE. In the traditional Eclipse IDE world, that was done with RCP applications.

With Eclipse Che 7, you’ll be able to plug any tool you want into a Che workspace:

It can be based on Eclipse Theia (which is a framework to build a web IDE), such as the popular Sirius on the web: See the youtube video.

Check out Red Hat CodeReady Workspaces for Red Hat OpenShift (Beta)

Built on the open-source Eclipse Che project, Red Hat CodeReady Workspaces provides developer workspaces, which include all the tools and the dependencies that are needed to code, build, test, run, and debug applications. The entire product runs in an OpenShift cluster hosted on-premises or in the cloud and eliminates the need to install anything on a local machine.

]]>0Doug Tidwellhttp://dougtidwell.comhttps://developers.redhat.com/blog/?p=5281772018-10-17T15:19:54Z2018-10-16T17:27:46ZEclipseCon Europe is almost here, and many Red Hatters are working furiously to make the show as valuable as possible for attendees. (We’re partly doing it for ourselves as well, of course, because it’s a great opportunity to get the entire Che/Theia community together.) If you aren’t familiar with Eclipse Che, it’s is a next-generation […]

]]>EclipseCon Europe is almost here, and many Red Hatters are working furiously to make the show as valuable as possible for attendees. (We’re partly doing it for ourselves as well, of course, because it’s a great opportunity to get the entire Che/Theia community together.) If you aren’t familiar with Eclipse Che, it’s is a next-generation cloud IDE and developer workspace server for teams and organizations. Theia is an extensible open-source framework to develop multi-language IDEs for the cloud and desktop using state-of-the-art web technologies.

The conference will be held next week on October 22–25 in Ludwigsburg, Germany. Here’s a rundown of what will be offered.

First, on Monday, October 22nd is the Che and Theia Contributor Summit, featuring luminaries from across the community. The day starts with sessions on Theia internals and customizing your experience with Theia, continues with presentations on how to deploy developer tools in sidecar containers and work that is being done to enable Che to run on any Kubernetes distribution. You can also take a tutorial to learn how to develop a plug-in for Che, including extending both the server side and client side. And that’s just the morning.

After lunch, we’ll hear about the experiences of community members who are extending the developer experience on Che and Theia with language servers, debuggers, and modeling and tracing tools. “Enterprise ready” is a term that gets thrown around a lot in the world of IT products, and the afternoon features a presentation on what a developer platform for enterprise application development should be in terms of security, scalability, reliability, and other features.

Finally, we end the day with collaborative community sessions sketching the future direction of both projects, before adjourning to the Eclipse Community Day meet-and-greet reception.

The conference proper runs from Tuesday (October 23) through Thursday (October 25). Here are some of the Che-related sessions and tutorials Red Hatters will be presenting:

]]>0Aurélien Pupierhttps://developers.redhat.com/blog/?p=5048272018-07-09T19:59:52Z2018-07-10T11:00:53ZApache Camel URI completion has already been available for XML DSL in Eclipse Desktop, Eclipse Che, Red Hat OpenShift.io, Visual Studio Code and IntelliJ. However, for Java DSL it was available only in IntelliJ. But Visual Studio Code and Eclipse Desktop are now also providing the Apache Camel URI completion for Java DSL. Below, you can see […]