我们正在努力解决如何以正确的方式使用功能。
假设我们的插件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家伙似乎使用“每个模块一个功能”的方法。毫不奇怪,因为它是唯一有效的。但他们不使用目标平台或产品文件。
答案 0 :(得分:0)
成功分组的关键是何时使用"包括"在功能和何时只使用依赖项。区别在于"包括"确实包括在内,即p2将始终安装包含的捆绑包和/或包含的功能。这就是为什么你需要在每个功能中更新捆绑包的原因。如果您不更新它,您将在安装中获得多个版本。
此外,在旧时代,必须指定功能中的依赖项。这些天,p2将主要从捆绑中找出依赖关系。因此,我实际上会停止在功能中指定依赖项,但只包括。将功能视为指定聚合内容的一种方式。
分组的另一个关键点是 - 少即是多。如果您拥有与捆绑包一样多的功能,那么您可能会遇到粒度问题。相反,请考虑用户将单独安装什么。对于用户永远不会单独安装的东西,不需要具有四个功能。不应将功能理解为对开发/项目结构进行分组的方式 - SCM中的文件夹或不同的SCM存储库中的文件夹是可以的。将功能视为部署结构。
通过这种方法,我建议使用类似于以下示例的结构。
<强> my.product.base 强>
<强> my.product.base.dependencies 强>
<强> my.addon.xyz 强>
<强> my.addon.xyz.dependencies 强>
现在在产品定义中,我只列出my.product.base。无需列出依赖项功能。 p2将自动获取并安装依赖项。但是,如果要将产品绑定到特定版本的依赖项,并且不希望p2选择任何匹配的版本,则必须包含my.product.base.dependencies功能。
在目标定义中,我将包含一个&#34; my.product.sdk&#34;特征。该功能是所有其他功能的聚合功能。它使目标平台管理更容易。我通常会创建一个包含所有内容的sdk功能。
另一个经常出现的特征是&#34; master&#34;特征。这是&#34;一切&#34;在构建期间可能用于创建p2存储库的功能。然后,生成的p2存储库用于组装产品。
有关更真实的示例,请参阅此处: http://git.eclipse.org/c/gyrex/gyrex-server.git/tree/releng/features
功能和持续投放
有关feature.xml
的频繁更新的评论。只有在结构发生变化时才需要修改feature.xml
。修改捆绑软件版本时不需要进行更新。您应该在版本为0.0.0
的功能中引用捆绑包。这使Tycho在构建时填写了正确的版本。因此,您需要做的就是将更改提交到任何包,然后启动重建。 Tycho还负责根据所包含的包的限定符更新功能限定符。因此,新的要素限定符将与之前的版本不同。