Sar*_*res 2 java osgi declarative-services bndtools enroute
在我的工作场所，他们让我学习 OSGi 框架并决定使用它的最佳方法是什么。
在过去的两周里，我在网上冲浪，发现了很多使用 OSGi 的不同方法，例如，我发现了 OSGi enRoute 方法和一个名为 BndTools 的 Eclipse 插件。我发现我可以简单地使用声明式服务或像 AIOLOS 这样的框架。
我对所有这些不同的方法和技术感到有些困惑……对于初学者来说，您认为开始使用 OSGi 的最佳方法是什么？是否有比其他实现更好的实现（例如 Equinox）？您有使用此框架的首选方法吗？
非常感谢您提前！
更新为了更好地解决这个问题，我写了一本小册子和视频，可以让您快速了解 OSGi。它非常具有交互性，使用 Bndtools 和 OSGi Gogo shell。你可以在这里找到它。
更新文本以提高可读性和当前状态
我能理解这种困惑……有很多构建工具，现在它们都支持 OSGi。由于您有时需要工具组合，因此空间很复杂。
要使用 OSGi，您需要构建bundles。包是 JAR 文件，是 Java 库/可执行文件的默认格式。当JAR 文件中的清单包含 OSGi元数据时，它们是包。此元数据向工具和 OSGi 框架提供信息，它需要从运行时获得哪些功能以及它向运行时提供哪些功能。此信息用于组装运行时以及在运行时验证事物是否兼容。
手动维护这些信息是一项令人作呕的工作。出于这个原因，bnd是我在大约 19 年前开发的。bnd 是目前业界主要的库来创建元数据，简化元数据的修饰，验证元数据的有效性。它对包进行广泛的分析和注释，以最大限度地减少手动工作。
在 bnd 情况下，它还支持声明性服务、清单注释等的 OSGi 标准构建注释。（许多 OSGi 标准起源于 bnd。）
IDE 是读取、编写和调试代码的首选工具。但是，如果没有在远程服务器上运行的持续集成解决方案，您就不能依赖结果，因为您的 IDE 可能依赖于您仅在笔记本电脑上拥有的信息。因此，对于专业开发，必须有一些服务器可以在不使用缓存的情况下从头开始构建您的软件。
显然，最重要的是，当您在笔记本电脑上开发软件时，结果与在服务器上构建时的结果相同。为此，bnd 提供了一个可在 IDE 和不同构建工具中使用的库。尽管 bnd 有无数种可行的组合，但最受欢迎的组合却寥寥无几。
Maven 是一种流行的 Java 应用程序构建工具。它定义了 POM（项目对象模型）文件中的所有构建信息，这些文件是 XML 文件。POM 可以从其他 POM 继承。每个 POM（和工件）由组ID、工件ID 和不透明版本标识。Maven 有一个非常固定的项目结构。所有构建工作都是通过从 POM 获取配置的插件完成的。
有两个基于 bnd 的 Maven 插件提供必要的 OSGi 元数据生成。
在此模型中，bnd 仅用于提供 bundle 中的元数据。所有依赖项都必须在 Maven 存储库中。
还有第三个插件 Tycho，它使用 Eclipse PDE 模型构建包。我听说今天很少有人推荐使用 PDE/Tycho，这并不是一个轻松的开发，许多 PDE 用户正在寻找替代方案。这个插件必须弥合 PDE 和 Maven 之间非常大的语义鸿沟。
尽管 Gradle 也依赖插件来完成所有低级工作，但它严重依赖 Groovy 来提供构建操作。
bndtools 组提供了一个插件，可以在普通 Java 构建中轻松生成 OSGi 元数据：
在此模型中，所有依赖项都必须存储在 Gradle 可访问的存储库中，这些存储库通常是 Maven 存储库。
在这个四重奏中，Eclipse 是基本的 IDE，M2E 是一个插件，它教 Eclipse 如何根据 maven 规范（pom 文件）构建包。在这个四重奏中，bnd 作为插件在 Maven 中运行。Bndtools 提供了一些 M2E 缺乏的额外 OSGi IDE 功能。这主要集中在为 OSGi 运行时创建程序集和查看包。
在这个模型中，所有构建信息都存储在 Maven POM 中。这是 BJ Hargrave 在这个问题的另一个答案中发布的模型。
在此模型中，bnd 仅用于提供 bundle 中的元数据。所有依赖项都必须在 Maven 存储库中。
另一个专门为 OSGi/bnd 开发的模型是 bnd工作空间模型。在这个模型中，工作空间是一个包含 OSGi 捆绑项目的目录，一个特殊的目录 ( cnf) 保存工作空间范围的信息。所有构建信息都存储在bnd很好的旧 Java 属性文件中。
Eclipse/Bndtools 和 Gradle（以及 Ant！）有一些插件可以读取工作区和项目目录中的信息，并教导它们各自的构建工具源在哪里、二进制文件应该存储在哪里等。这些工具的插件使用 bnd 的人会竭尽全力确保构建结果相同。
原始存档的 OSGi enRoute基于此模型。尽管已存档，但它仍然是 Bndtools 的主要模型，并被许多公司使用。在 EclipseCon 2018 上有几个关于这个模型的演示：
这也是 OSGi 自己用来构建规范 JAR、参考实现和合规性测试套件的模型。
bnd 工作空间模型是唯一支持所有存储库标准的模型。这包括 Maven 存储库（Maven Central！）、OSGi 存储库标准、Eclipse P2 存储库、基于目录的存储库，甚至基于 POM 的存储库。bnd 工作空间模型中对外部存储库的支持非常灵活。
通常，从 OSGi 开始的开发人员已经具有 Java 经验。这通常会促使他们选择工具，因为已经有一个遗产。
如果您可以从一张白纸开始，那么我个人的偏好是 bnd 工作区模型。它将优先级放在 IDE 上，这是您花费大部分时间的地方，同时对持续集成构建具有极好的保真度。在过去的两年里，我帮助过两家公司，一家从零开始使用 OSGi，另一家拥有 8 年的 PDE 经验。两者现在都基于这个工作区模型，我对他们如何能够在没有任何先前经验的情况下获得 OSGi 的好处印象深刻，这比我以前见过的要快得多。
可以在此处找到使用 Bndtools 和 OSGi Gogo shell 的交互式教程。带视频！