在上一篇中，我们描述了如何为代码生成提供支持和创建自定义堆栈。

目前为止，我们还没有为扩展Che添加任何一段代码。我们使用Che的workspace的概念，演示了如何将其作为一个docker容易添加工具。英文浏览器IDE允许我们在运行时执行任何指令，我们暂时不需要实现什么东西去扩展它。

然而有一些需求，增强workspace是不够的。当你想用新特性增强浏览器IDE的UI或者你想在workspace运行时添加新的API。

在这片博文中，我们将描述，如何为浏览器IDE创建一个镜像增强，以简单的hello world为例。这方便我们初步了解扩展Che的整个流程。我们将在之后的博文中，做更复杂的扩展。

我们EclipseSource的工作者都有着多年的为Eclipse的IDE添加扩展和建立基于Eclipse的应用的经验。所以，在了解细节之前，我们从一个桌面Eclipse IDE开发者的角度总结我们拓展Che的经历。我们主要关注最明显的相似点和不同点。

相似点：Eclipse Che有着可以灵活扩展的框架。主要是由于其服务导向的核心模式。有几种不同的方式将其用于拓展。

• Che提供的服务可以在UI中构建几乎任何东西。作为一个实例，che提供了一项服务来注册菜单栏对应的操作。作为另一个例子，也有注册文件扩展名的服务（指定相应的图表和默认的编辑器）。这些服务可以被分层到不同的UI对象，比如不同的菜单、面板和布局等等。
• Che提供访问源文件、工作空间运行时的服务。利用这些特性，在顶部添加新功能很简单。
• Che的服务器主要是RESTful服务的集合。通过向服务器添加自定义的REST服务，你可以轻松的加强Che。因此，自定义的服务可以通过浏览器IDE中的自定义的扩展来调用。
• 最后，Che定义了服务接口，可以通过扩展之后提供新内容。比如，你可以实现一个服务，这个服务可以实现一个创建自己定义项目的工作。

区别：目前在Che中没经典的Eclipse IDE中的运行时插件机制。这就意味着，如果你想扩展Che，你需要build一个包含你的插件的自定义的版本，并且将整个程序部署在某个地方。技术上说，Che开面的插件是maven模块，是你在编译的期间添加到全局框架里的。浏览器IDE在运行时没有可扩展性。那么，和经典的Eclipse IDE相比，这岂不是一种倒退？关于这个问题，不同的人有着不同的观点：

• 不，因为Che支持的运行时可扩展性，基于它的工作空间的理念。如果你在运行时缺少任何工具和组件，只需要将其扩展到工作区间，然后与同事们共享即可。作为实例，我们运行时增加了EMF代码生成的支持。而在一个景点的Eclipse IDE中，每个人都需要再次安装相同的东西(至少在不使用Oomph时)。
• 部分意义上，在运行时，你只能扩展工作空间，而不能扩展浏览器IDE和Che的服务器。但是，Che有一个不同的部署方案。由于它是一个服务器-客户端类型的应用，想法就是对其做一次集中的设置，然后共享给一批需要相同工具集的开发者。这样可以为项目开发者提供一个快速的配置方式。它甚至可以用不同的IDE去访问同一个workspace。但是，这意味着作者和插件维护者需要更多的工作，但对开发者来讲很简单。
• 是的，我们失去了OSGi,p2库和扩展点。虽然前两者过去一直被批评，但仍是一个构建模块化和可扩展应用程序的强大组合。将其与Eclipse提供的强大的工具结合，可以进行有效的开发、安装、更新和部署IDE扩展。这是一个庞大的工具生态系统的核心要素之一。

所以最后，它实际上取决于场景和你的设计目标。值得一提的是，有一个大趋势（也跟随Che）是将IDE的UI相关部分移动到服务器端抽象中，以便它们变得独立。语言服务器协议就是一个很好的例子。在这种情况下，IDE只需支持解释抽象，例如LSP。因此，客户端站点的可扩展性可能变得不那么重要了。

Anyway，我们先开始在本地建立Che。

首先，您需要安装所有必备条件来构建和运行Che。我们已经提到过你需要Docker，但是构建Che还需要一些工具和环境设置。

有两种方式可以采用。我们推荐一开始没有目的的，根据指南来复制和构建che。第二步，如果你想使用IDE，我们建议阅读Che的工作空间指南。

我们推荐大家花时间认真读提供的文档，因为它包含着对开发Che的工作很有用的信息和提示。你可以关注一下超级开发模式，它允许替换GWT应用程序的热代码，因此大大减少了在浏览器IDE上工作时的周转时间。

还有一个选项可以在预配置的Docker环境中构建Che，这样可以省去自己设置它的麻烦。但即使你的电脑运行速度很快，Che也需要花很长时间才能完成。所以，我们建议你看一下我们会在这里详细介绍的这些选项。

构建的过程主要由一些构件组成，在Che的术语中，称之为assembly。你可以在assembly的子目录找到它们。您可以通过将目录与体系结构进行比对，从而将assembly与Che体系中的组件进行匹配。

构建完成后，您可以在本地计算机上启动Che。最简单的方式是打开到assembly/assembly-main/target/[che-version]/[che-version]目录，然后执行bin/che.sh start。会有一大堆的log信息，最后你在浏览器打开localhost:8080，应该就能看到che的dashboard。

那么现在，我们能在本地建立che了，让我们做一些小改动来验证build的过程。一个简单的修改样例，就是向浏览器IDE添加一个模板项目。模板项目可以由IDE的用户自己选择。比如我们开发EMF支持的时候，可以用示例EMF项目作为模板。在这一系列博文的第二部分，我们是从git手动导入的，现在我们要将其作为固定的模板添加到我们的自定义assembly里面。

模板项目基本上都是指向现有git存储库的指针。这样就可以轻松维护模板，而无需重新分配IDE本身。样例模板在以下文件中维护：

ide/che-core-ide-templates/src/main/resources/samples.json

将下面一段代码加入到这个文件里

{
   "name": "emfforms-makeithappen-blank",
   "displayName": "emfforms-makeithappen-blank",
   "path": "/",
   "description": "EMFForms, make it happen!",
   "projectType": "java",
   "mixins": [],
   "attributes": {
     "language": [
       "java"
     ]
   },
   "modules": [],
   "problems": [],
   "source": {
     "type": "git",
     "location": "https://github.com/eclipsesource/emfforms-makeithappen-blank",
     "parameters": {}
   },
   "commands": [],
   "links": [],
   "category": "Samples",
   "tags": [
     "maven",
     "java"
   ]
 }

之后我们需要通过执行“bin / che.sh stop”来停止当前运行的che实例，重建Che然后使用“bin / che.sh start”再次启动它。

这样新的模板项目就可以使用的了。

当然，这是一个非常简单的改变，它甚至不涉及任何代码。但是，我们现在准备进行更复杂的更改并开始编写代码。请注意，在我们的示例中，我们更改了Che的配置文件以添加我们的自定义项目模板。这种扩展通常是通过调用服务来完成的，这些服务允许扩展Che的基本配置（在我们的例子中添加一个新的项目模板）。 我们将在本系列的后面部分回到这个更简洁的解决方案。

当开始为扩展Che写代码时，这些扩展通常被放置在分离的maven模块（即插件）中。这在概念上非常类似于为经典Eclipse开发插件。 这意味着，自定义代码将与Che的核心分开。我们将在本系列的下一篇博客文章中详细描述这一点。 作为示例，我们将创建插件，该插件为“.ecore”注册自定义文件类型，包括自定义图标。