如何将插件分组为功能

Question

我们正在努力研究如何正确使用功能。

假设我们有插件org.acme.module，它依赖于org.thirdparty.specific 和org.acme.core。

我们有插件org.acme.other，它依赖于org.acme.core。

我们想从这些文件中创建一个应用程序，其中包括一个目标文件和一个产品文件。我们有以下选择：

每个模块一个功能：

• org.acme.core.feature
  • org.acme.core
• org.acme.module.feature
  • org.acme.module
• org.acme.other.feature
  • org.acme.other
• org.thirdparty.specific.feature
  • org.thirdparty.specific

这使得目标和产品文件非常庞大，并且依赖项很难手动管理。

每个依赖组一个特性：

• org.acme.module.feature
  • org.acme.core
  • org.acme.module
  • org.thirdparty.specific
• org.acme.other.feature
  • org.acme.core
  • org.acme.other

这种方法使依赖关系非常易于管理，并且目标和产品文件易于阅读和维护。但是它根本不起作用。在org.acme.core 发生变化的那一刻，您需要更改所有功能。此外，应用程序对打包什么没有发言权，因此它甚至无法决定更新org.acme.core（由于错误修复或其他原因）。

平台特点：

• org.acme.platform.feature
  • org.acme.core
  • org.acme.other
  • org.thirdparty.specific（但可能是它自己的功能）
• org.acme.module.feature
  • org.acme.module

这是用于 Hello World 应用程序和 Eclipse 附加组件的方法 - 它仅适用于这些。由于所有模块的目标平台都指向org.acme.platform.feature，因此每当任何平台插件发生任何变化时，您都必须相应地更新org.acme.platform.feature。

我们实际上只使用了大约 50 个平台插件就尝试了这种方法。让开发人员为每个错误修复更改功能是不可行的。 （虽然 Tycho 支持版本“0.0.0”，但 Eclipse 不支持，所以使用它是另一个问题。此外，我们需要可重复性，所以让 PDE 选择版本是不可能的。）

这一切都归结为“我无法使用 org.acme.platform.feature 并在两周内覆盖 org.acme.core 的版本，直到新功能发布。

---

整个问题变得更加困难，因为有时可能有不止一种插件配置（比如说针对不同的数据库提供者），然后有高级模块使用其他子模块才能正常工作，这必须以某种方式进行管理。

我们缺少什么吗？其他公司如何处理这些问题？

Eclipse 家伙似乎使用“每个模块一个功能”的方法。毫不奇怪，因为它是唯一有效的。但他们不使用目标平台或产品文件。

Answer 1

成功分组的关键是何时在功能中使用“包含”以及何时仅使用依赖项。不同之处在于“包含”确实包含在内，即 p2 将始终安装包含的捆绑包和/或包含的功能。这就是为什么您需要更新每个功能中的捆绑包（如果包含）的原因。如果您不更新它，您最终会在安装中获得多个版本。

此外，在过去，我们必须在特性中指定依赖关系。这些天来，p2 将主要从包中找出依赖关系。因此，我实际上会停止在特性中指定依赖关系，而只是包含。将特征视为指定聚合内容的一种方式。

分组的另一个关键点是 - 少即是多。如果您拥有与捆绑包一样多的功能，那么您很可能会遇到粒度问题。相反，请考虑用户将单独安装什么。对于用户永远不会单独安装的东西，不需要有四个功能。不应将功能理解为对开发/项目结构进行分组的一种方式——这就是 SCM 或不同 SCM 存储库中的文件夹可以使用的地方。将功能视为部署结构。

使用这种方法，我会推荐类似于以下示例的结构。

my.product.base

• 包含产品最低限度的基本功能
• 可以是 org.acme.core 加上一些最少的

my.product.base.dependencies

• my.product.base 的第三方库的功能

my.addon.xyz

• 功能捆绑插件
• 可以单独安装的东西的单独功能

my.addon.xyz.dependencies

• 用于附加依赖项的第三方库

现在在产品定义中，我将仅列出 my.product.base。无需同时列出依赖项功能。 p2 将自动获取并安装依赖项。但是，如果您想将您的产品绑定到特定版本的依赖项并且不希望 p2 选择任何匹配的版本，那么您必须包含 my.product.base.dependencies 功能。

在目标定义中，我将包含“my.product.sdk”功能。该功能是所有其他功能的聚合功能。它使目标平台管理更容易。我通常为所有内容创建一个 sdk 功能。

另一个经常看到的功能是“主”功能。这是一个“一切”功能，可用于在构建期间创建 p2 存储库。然后将生成的 p2 存储库用于组装产品。

有关更真实的示例，请参见此处： http://git.eclipse.org/c/gyrex/gyrex-server.git/tree/releng/features

功能和持续交付

有一条关于频繁更新feature.xml 的评论。一个feature.xml只有在结构发生变化时才需要修改。修改捆绑包版本时无需进行更新。您应该在版本 0.0.0 的功能中引用捆绑包。这使得 Tycho 在构建时填写正确的版本。因此，您需要做的就是对任何捆绑软件进行更改，然后开始重建。 Tycho 还负责根据包含的捆绑包的限定符更新功能限定符。因此，新的功能限定符将与以前的版本不同。