Eclipse Che的在线开发平台度过了美好的一年。 在2018年初，Eclipse Che 6.0发布了，它为有兴趣创建云原生应用程序的开发团队提供了许多新功能，在CheConf 18.1会议上，宣布了下一个开发阶段的开始-Eclipse Che 7。
在每个新版本中，由于社区的努力和用户的积极参与，该平台变得越来越有趣。 让我们看看可用的机会如何改变和扩展，以及如何立即尝试。
Eclipse Che是一个开源项目，其目标如下：
- 加快新参与者与项目之间的联系。
Eclipse Che只需要一个浏览器即可工作。 不需要在开发人员的计算机上安装其他软件，这意味着新人们可以立即参与工作。 - 解决工作环境不匹配的问题。
“嗯，我不知道！ 一切都在我的机器上工作！” -听起来很熟悉吗？ 这将不再发生：现在，代码在所有工作站上都相同。 - 提供内置的企业级安全性。
由于Eclipse Che定位为VDI解决方案的替代品，因此它必须符合公司的安全要求，尤其是具有基于角色的访问模型，并且极不可能在开发机器上存储源文本。
该项目路线图概述了四个主要领域：
- IDE.next-更新的代码编辑器-更加有趣
- 插件是Che生态系统进一步发展的关键。
- Workspace.next-以容器化微服务形式工作的IDE工具，可以提高开发和生产环境的一致性。
- 完整的企业功能 。
还有更详细的信息吗？
IDE。下一步
Che的新版本代替了基于GWT的IDE，现在使用
Eclipse Theia ，从而扩展了进一步开发Eclipse Che项目的可能性。
查看新IDE的工作原理：
现在可用：
- 基于Monaco的编辑器 -超级快速和超级响应式界面，codelens功能等等。
- Command Palette ，它使您几乎可以用键盘进行任何操作。
- 任务支持 ，包括VS Code和Che团队的任务。
- 直接从IDE 内置的应用程序预览 ，包括Markdown模式。
- 可自定义的界面 ，遵循拖放原理。
- 等等，包括“大纲视图”，“搜索”，“ Git”。
蚀神
如您所知，Eclipse Theia是用于创建在线IDE的平台。 该项目基于TypeScript，为开发人员提供了更方便，更灵活的编程模型，从而加快了插件的创建速度。
但是，Che项目中当前使用的Eclipse Theia与IDE之间存在严重的功能差距。 因此，在过去一年的大部分时间里，Theia添加了缺少的功能，以便可以完全替代当前的IDE。 Eclipse Che项目的贡献者已经花费了五年多的时间来创建基于云的IDE，因此，保持基础知识和经验对于使新的IDE真正有用非常重要。
以下是有用功能的示例：
- 调试适配器协议。
- 语言服务器协议。
- 指令
- 设定值
- 键盘快捷键。
- Textmate支持。
- 安全功能。
针对不同用例的不同IDE
另一个重要的细节。 与以前一样，默认情况下，Che将为工作区提供其默认的Web IDE。 但是，现在可以将其他IDE连接到它们，因为在某些情况下，Che的IDE环境无法涵盖必要的用例，或者由于某些原因，某些人应该使用某些特殊的工具。 在旧的IDE中，RCP应用程序用于此目的。
在Eclipse Che 7中，可以将任何工具连接到工作区（Che工作区），包括：
- 基于Eclipse Theia的工具（因为它只是构建在线IDE的平台），例如流行的Sirius工具。
- 绝对其他解决方案，例如Jupyter或Eclipse Dirigible。
看一下将Jupyter与Che工作区结合使用的示例：
顺便说一下，Eclipse Dirigible团队也在努力将其在线IDE与Che工作区集成在一起。
Eclipse Dirigible集成到Eclipse Che工作区中。 更多在此
链接 。
新的Che-Plug模型
Eclipse Che是一个用于构建基于云的工具的平台，为此，它需要一个经过深思熟虑且方便的可扩展性模型。
Eclipse Che的可扩展性通常可以归结为白色标签：第三方开发人员帮助创建了自己的Eclipse Che定制版本并将其分发给受众。 尽管这适合许多合作伙伴，但该方法始终被认为很复杂，并导致出现了技术堆栈（尤其是IDE中的GWT），这对于开发人员而言并不是特别方便。 由于缺乏动态可扩展性，必须将Che Plugin组件包装到所谓的“装配体”中，以使最终用户可以使用它们。 另外，如果不重建整个Che环境，基本上不可能快速创建一个插件，将其打包以安装在现有Che环境中，并使该插件可用。 这就是为什么我们离开GWT来支持Eclipse Theia IDE项目的原因。
创建动态插件模型需要所有这些操作。 简而言之，在Che中，用户不必担心在其工作区中工作的工具的依赖性，它们应根据需要变得可用。 这意味着Che-plugin本身提供了它的依赖关系，它的后端服务（可以在连接到用户工作空间的辅助容器中工作）以及其IDE的UI扩展。 结果，用户会觉得Che在工作空间中神奇地提供了他们所需的语言服务和开发工具。
VSCode兼容
新的插件模型具有另一个重要方面：简化开发人员创建插件并将其作为各种工具的一部分或在社区内分发的努力。 因此，Theia插件已对其API进行了补充，以确保与VS Code扩展点兼容。 结果，大大简化了将现有插件从VS Code移植到Eclipse Che的过程。 主要区别在于打包方法：在Eclipse Che中，插件和依赖项都打包在其自己的容器中。
像这样：
为了简化发布和分发，将启动一个插件市场。 此外，它将以社区可用的公共服务的形式以及单独功能的形式实现，该功能允许您创建此类存储作为私有Che环境的一部分，并对防火墙进行严格的内容控制。 现在，您可以在相应的github存储库注册表中找到插件。
托管模式
创建Che-plugins应该很容易，并且在内部开发周期中要花尽可能少的时间（我们现在正在谈论对代码进行更改与查看和调试这些更改的结果之间的差距）。 并且由于需要对基于GWT的IDE进行重大改进，因此实现了新的托管模式。 这种模式允许Che项目的参与者直接从Che本身构建Che，并提供完整的生命周期支持，从创建和编码新插件到调试它。
看起来是这样的：
面向Kubernetes的IDE
Eclipse Che 7是第一个面向Kubernetes的IDE。 也就是说，您可以直接在工作区域中使用容器。 在Che中，这些区域具有特殊的逻辑级别“开发模式”，该模式在生产环境中使用的容器之上实现，并在进入IntelliSense和其他辅助IDE工具时提供自动完成工具。
至于Workspace。接下来，由于有了它们，您可以立即在Che中使用“干净的”应用程序定义（Docker映像，Composefile或Kubernetes资源列表），而无需进行任何修改即可实现IDE服务。 在Workspace.Next中，IDE工具被实现为微服务，与相关性一起打包在其自己的辅助容器中，并且不会以任何方式影响应用程序容器。 在运行时，IDE工具彼此隔离，并且与应用程序容器隔离。 结果，每个IDE工具都有其自己的生命周期，从而简化了它们的更新和替换，并且很快它们将收到自己的扩展机制。
怎么尝试？
Eclipse Che 7可用，您现在可以通过在创建新工作区时选择Che 7堆栈来进行试用。
转到工厂URL：
https :
//che.openshift.io/f?id=factoryvbwekkducozn3jsn在che.openshift.io上创建一个帐户，创建一个新的工作区并选择Che 7堆栈。
要测试吗？ 安装最新版本的Eclipse Che：Eclipse Che
快速入门如果您准备分享您的想法和意见，请加入社区！
支持：问题，错误报告，通过
GitHub问题进行的功能请求
一般聊天： eclipse-che Mattermost频道
虚拟会议： Che社区会议每隔一个星期一举行一次
邮件列表： che-dev@eclipse.org
可以从此处的开发人员订阅中下载
Red Hat CodeReady工作区 ：
https :
//developers.redhat.com/crw-hw/