针对OSGi平台版本之间的兼容性的建议

Question

假设甚至有可能，在不同的平台版本之间使用捆绑包可以实现什么样的推荐？特别是在R3和R4之间。

更新我的要求：

的想法是开发针对目前运行一个OSGi R3的容器，但它可能很快就会升级到R4一个嵌入式设备网络接口（我们没有太多控制这个）。 Web界面将使用OSGi HTTP服务进行部署。我看到三个选项：

• 使用R4执行应用程序，因为我发现某些Web工具包不适用于旧版本。我猜想，该设备的提供商可以在R4上部署当前的R3捆绑包，而不需要太多努力（但不确定）。
• 使用R3实现Web界面，没有现代Web工具包的好处（或推荐给我一个）。
• 使用一些R4捆绑包，但是某种方式独立发布，因此我们可以最终在R3或R4上部署它。

Answer 1

一般来说，R4主要为bundle清单引入了新的头文件，R3实现忽略了这些头文件。导入/导出行为存在一些语义差异，但取决于您制作的是哪种包，这些可能无关紧要。你可以使用的一个策略是简单地创建一个R3包，它应该在R4框架上仍然可以正常工作。当然，在这种情况下，你会错过一些新的R4功能。

追问：

从视HttpService的点，没有大的变化，从R3去R4.2。前者使用HttpService的1.1规范，后者是1.2。差异很小（规范使用API​​文档中的@since标签来解释什么时候引入了什么方法）。

R3捆绑套件在R4上的工作原理完全正确。请记住，在实践中，您可以在R4中运行R3软件包时发现错误。当R4刚刚发布时，我将一个大型项目从R3迁移到R4，我们遇到了很多小问题，这都是我们自己的错误，这导致了在R4上运行的捆绑包在R3上快乐地运行时失败。这些主要与R4的实现在涉及委托给它们的父类加载器时通常更加严格相关。确保你在你想部署它们的框架上测试你的bundle。

我想知道，你看的网络工具包以什么方式不能在R3上工作？他们依赖于HttpService 1.2吗？我想在R3上运行1.2并不难，或者将它与1.1的实现联系起来。

Answer 2

我从R1开发了捆绑包，他们仍然在R4框架上运行。向后兼容性是规范工作的重点。但正如马塞尔所指出的那样，关于您的需求的更多细节将会有所帮助。

更新 有没有商业或技术要求，你不能使用R4？那么，如果你只是使用标准的HttpService实现一个基于servlet的服务，那么当把这个bundle移动到一个R4框架时你不应该期待任何问题。但是你可以也应该开始使用R4清单属性。它们在R3中被忽略，但在解决R4和更高版本中的依赖性方面非常有用。

如果您仅限于R3框架，我会经常在R4框架上并行进行测试，以确保一切正常。没有太多的努力。