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