osgi模块化规范_OSGi Core和Enterprise 5规范关闭

osgi模块化规范

在OSGi联盟博客上，即将离任的OSGi联盟技术总监Peter Kriens透露，他的天鹅歌曲– OSGi Release 5的画龙点睛，有人可能说这是Kriens的巨著。

Kriens补充说，全新的“核心”和“企业”规范将在适当的时候出现，一旦它们通过了专家组和各种律师的眼球。 幸运的是，对于Eclipse社区中的人来说，可以在下周的EclipseCon / OSGi DevCon上看到它的草案。 根据OSGi的推广者，OSGi版本5的最大部分-期待已久的OSGi需求能力模型。

Kriens 详细介绍了创建用于处理Java依赖关系的通用模型所需的工作量 ，并谈到了为什么需要进行更改：

我们的行业没有办法描述这些无数的依赖关系，因此解决方案是 配置文件 的泛滥 。 而不是只有100个依赖项。 不幸的是，该单个依赖项合计了1000个依赖项，其中900个您可能会在意。 哦，是的，它实际上并没有您真正需要的一种依赖。 配置文件是软件的警钟，它们用一种简单的解决方案引诱我们，这是出乎意料的错误。

在 RFC 112 OSGi Bundle Repository （OBR）的步骤中，它完全改变了思维方式，Kriens和Richard S. Hall 开发了一种语言来表达能力和要求。 OSGi开始描述依赖关系，该模型对于泡菜的开发人员非常有用，尤其是在扩展器中。

克里恩斯补充说：

每个捆绑包都完全可以通过“需求能力”模型进行自我描述。 这使自动组装组件成为了圣杯（好吧，差不多了）。 现在甚至可以考虑本地功能，从资源中自动找到最小的传递依赖项集。 对我而言，此模型的最大优点是它消除了对“应用程序”的需求。 任何捆绑软件都可以成为“应用程序”，因为现在可以自动包含任何依赖项。

Kriens将自己的卡片贴在胸前，向他们揭示了Release 5的一些新花样，例如由Resolver服务和Repository服务使用的通用API。 Resolver服务提供对OSGi感知解析器的访问，该解析器可以获取资源并找到一组资源的关闭，而Repository服务则提供对本地或外部存储库的访问。

正如先前报道的那样，Kriens即将离开OSGi牧场联盟，但表示需求能力模型是OSGi中“自服务以来最具创新性的部分”。 他还说，尽管他不活跃在OSGi联盟中，但他将来可能会涉猎它。

祝彼得今后的事业一切顺利。 最后的发行版肯定会巩固他的遗产，在采用革命性的动态模块系统OSGi方面发挥重要作用。

翻译自: https://jaxenter.com/osgi-core-and-enterprise-5-specifications-close-104287.html

osgi模块化规范