集中化 Eclipse 中的帮助功能

核心提示：长期以来，开发人员一直认为构建模块系统可以很容易地更新系统中的某个部分，集中化 Eclipse 中的帮助功能，而不影响系统的其他部分，模块性还可以通过新的方法很方便地对原始系统进行扩展，用于支持连续集成的 CruiseControl，以及其他大量的工具，这就是作为一组插件来构建 Eclipse 的动机，这允许其他开发人

长期以来，开发人员一直认为构建模块系统可以很容易地更新系统中的某个部分，而不影响系统的其他部分。模块性还可以通过新的方法很方便地对原始系统进行扩展。这就是作为一组插件来构建 Eclipse 的动机，这允许其他开发人员替代或增强已有的模块。

Eclipse 中的“帮助”与其他环境一样，是使用插件架构构建的。本文讨论了如何利用这个有用的架构来外部化帮助内容。本文假定您已具备 Java™、Eclipse 和 Web 主题方面的应用知识。但并不要求您了解在 Eclipse 中“帮助”是如何组织的，以及插件的工作原理方面的所有知识。本文的目的是向您说明在集中的服务器（企业内部网或 Internet）上承载 Eclipse 环境的“帮助”方法和原因以及如何从该环境中对它进行访问。

为什么要集中化？

Eclipse 中的“帮助”不是单块集成实体，而是为提供整体概念合并在一起的一系列插件。但即使这样，也没有真正回答以下问题：“为什么要集中管理 Eclipse 中的‘帮助’？如果下载 Eclipse 的 Java 版本，则可以进行 Java 开发，并且可以得到本地所需的所有帮助”。这对于整个开发小组也是如此。其中每个人都可以有自己的本地“帮助”副本，您可以很好地使用这些副本，一直到有一天出现额外的插件。

插件的到来

在实际的项目中，那一天将会到来，到时您会认识到自己以及开发小组的其他成员都需要一两个插件服务（或者由于它们经济实惠，您会需要更多的插件）。对于任何不平凡的小组开发工作，从构建过程到正在使用的第三方 JAR 文件都要确保每个人的环境是相同的。这只是一个项目的最佳实践：确保小组中的每个人都在构建同一事物。事实上，大量的第三方工具的作用只是处理这个实践，这些工具有：Ant、Java Make 工具，用于支持连续集成的 CruiseControl，以及其他大量的工具。经验丰富的 Java 开发人员认识到确保开发环境和过程在整个小组中可重复利用是一件较好的事情。为什么“帮助”又各不相同呢？