用于API和实现的单独OSGI捆绑软件是否常见？

问题描述

| 我有一个带有依赖项的类，我想在不重新启动依赖项的情况下进行热部署。该类有一个接口，但是只有一个具体的实现。 最初，我创建了一个带有导出接口的捆绑包，并使用未导出的激活器和实现类注册了实现。但是，如果我更新捆绑软件，则在调用PackageAdmin＃refreshPackages时，更新后将重启使用注册服务的捆绑软件（使用fileinstall时这是自动的）。 我已经通过创建单独的api包来解决此问题。 这是实现此目标的最佳方法吗？ 您是否有一个捆绑包可以导出其api，并将实现包含在同一捆绑包中。据我所知，任何赠礼包都将导出其所有类或不导出任何类。我想念什么？     

解决方法

        将API包与其在OSGi中的实现分开是绝对的最佳实践。如果执行此操作，则任何使用该API的捆绑包都仅需要从该API捆绑包中导入类，这可以使您在运行时更改实现而无需重新启动相关的捆绑包。 理想情况下，您的实现捆绑包将实现接口，并将实现导出为API提供的接口上的服务。这允许客户端捆绑包在不参考实现捆绑包的情况下利用服务。     ,        在Apache Sling中，我们两者都做：主要的API都在它们自己的捆绑包中，但是对于较小的东西（例如扩展件或可选组件），我们通常在与API相同的捆绑件中提供默认实现。 在后一种情况下，您仍然可以允许替换那些默认服务，例如，当您想覆盖它们时使用服务排名值。 包并不一定要导出其所有类，包含默认服务的包仅导出API包（显然，默认实现位于不同的包中）。     ,        除非在没有重新启动客户端捆绑包的情况下能够在运行时替换实现的硬性要求，否则我个人会主张在API和实现之间保持显式的依赖关系链接（通过在API捆绑包中包含impl类或通过具有API捆绑包）从impl。捆绑包导入实施包）。 具有上面建议的模式的pb是它们打破了依赖链。依赖关系管理的好处远远超出了简单的API兼容性，它们还包括确保可预测的一致运行时行为以及与部署生态系统的兼容性，所有这些都需要管理实现依赖关系。