在我工作的地方，他们要求我学习 OSGi 框架并决定使用它的最佳方法是什么。
在过去的两周里，我在网上冲浪，发现了很多使用 OSGi 的不同方法，例如，我发现了 OSGi enRoute 方法，以及一个名为 BndTools 的 Eclipse 插件。我发现我可以使用简单的声明式服务或像 AIOLOS 这样的框架。
我对所有这些不同的方法和技术有点困惑……您认为初学者开始使用 OSGi 的最佳方法是什么？是否有比其他实现更好的实现（例如 Equinox）？您有使用此框架的首选方法吗？
非常感谢您！
更新为了更好地解决这个问题，我编写了一本小册子和视频，让您可以快速进入 OSGi。它是非常交互式的，使用 Bndtools 和 OSGi Gogo shell。你可以在这里找到它。
更新文本以提高可读性和当前状态
我可以理解这种困惑......有大量的构建工具，现在它们都支持 OSGi。由于您有时需要组合工具，因此空间很复杂。
要使用 OSGi，您需要构建捆绑包。包是一个 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 仅用于提供包中的元数据。所有依赖项都必须在 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 仅用于提供包中的元数据。所有依赖项都必须在 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 上，这是您花费大部分时间的地方，同时对持续集成构建具有极高的保真度。在过去的 2 年中，我帮助了两家公司，一家从头开始使用 OSGi，另一家拥有 8 年的 PDE 经验。两者现在都基于这个工作空间模型，我对他们如何能够在没有任何先前经验的情况下获得 OSGi 的好处的速度比我以前看到的要快得多，这给我留下了深刻的印象。
可以在此处找到使用 Bndtools 和 OSGi Gogo shell 的交互式教程。带视频！
从 OSGi enRoute 开始。它将讨论使用 Bndtools 作为 IDE。它已经使用 Bnd maven 插件来构建包，并演示了使用声明式服务来编码提供和使用服务。