我正在开发一个 RCP 应用程序，我也在为它实现 p2 更新。
我使用此链接作为实施 p2 更新的指南。
例如，我的应用程序中有 3 个插件 A、B 和 C。
插件 A 代表我的应用程序的核心功能。插件 B 是另一种强制性插件。虽然插件 C 是可选的。
我创建了 3 个功能项目。其中 FeatureA 包含插件 A 和依赖库。
FeatureB 包含插件 B 和依赖库。而 FeatureC 包含插件 C 和依赖库。
这三个插件中有些库是通用的，例如 birt、nattable。我应该如何构建它们。目前我正在将它们单独添加到每个功能项目中。构建特色项目的更好方法是什么？请指导我。
当您拥有您的功能所需的插件的公共子集时，您可以创建另一个“要求”功能，其中包括所需的插件，然后在现有功能中要求该功能。这使您可以更轻松地随着时间的推移更改所需的插件集。
这种方法的一个缺点是功能 B 可能不需要通用功能中的所有插件，这意味着如果您在没有功能 A 的情况下发布功能 B，它可能会发布比您预期更多的插件。
您应该考虑的另一项是您是否会更新彼此独立的功能？如果您要求所有版本的功能都相同，那么拥有新的需求功能是有意义的。但是，如果功能 A 可以升级到 2.0 版，而功能 B 仍然是 1.0，如果您有单例插件，您将遇到配置冲突。
另一个想法是，由于您正在创建一个 RCP，您可能只想在您的产品文件上运行p2 发布程序以生成一个阵容 IU。这会为您的 RCP 应用程序提供更具确定性的配置。如果您正在创建一个没有标准 Eclipse About 对话框的简单 RCP，那么您甚至不需要公开特性。
最后一点，您可以购买更新功能。在过去的 5 年里编写了这项技术，我可以告诉你有很多陷阱。我公司的产品Secure Delivery Center可让您轻松发布软件并提供简单的更新支持。