现在看来，OSGi 是一个热门词汇。许多benefits被调用：
（等）
我要求一个非常具体的用例 - 中小型 Web 应用程序。 OSGi 会给这些带来什么好处？真的值得吗？
【问题讨论】：
我会一如既往地说“这取决于”。
您的环境
考虑一个没有 OSGI 经验的现有团队（他们自豪地认为自己是“完成任务”的经验丰富的开发人员。他们有可能会经历重大痛苦或起步缓慢。
很多（比您想象的要多）开发人员不熟悉 Ant 或 Maven 等构建工具，而且他们只使用这些构建工具的有限功能。
创建 OSGI 包最好使用 Eclipse、Ant tasks 或 Maven BND plugin VS 脚本或手动编写的 jar 存档清单。
小型应用程序
对于小型应用程序，OSGI 引入了不必要的复杂性，而您可以使用诸如Jython 等动态语言或诸如JPF 或SPI 之类的插件框架。你也可以直接使用反射和一个简单的自定义类加载器。
大型应用程序
大型应用程序可能会从 OSGI 中受益，尤其是当它们从头开始编写时。恕我直言，将 OSGI 集成到现有应用程序中更像是引入补丁以提供模块化架构。
根据我的经验，在重写了许多应用程序之后，最好在项目初期考虑模块化。
其他问题
部署： 在任何应用程序中都是一样的。如果您习惯于部署 Java Web Start 应用程序，那么部署就不是问题。如果您习惯于 OSGI，则不必担心部署。
在将任何应用程序部署到生产环境时，总会偶尔出现问题，这是很自然的。
版本控制： 有许多方法可以在应用程序中提供版本控制。但是，如果您仅将版本控制用作“信息”而不是工具（管理依赖项要求），则版本控制不是问题。
重用： 使用 OSGI 时，您倾向于编写代码以供重用，但任何编写良好的 API 在设计时都考虑到了代码重用。
Eclipse 是使用 OSGI 编写的成功的大型应用程序的第一个示例。还有其他不使用 OSGI 并且是模块化的大/好工具。
结论
在许多模块化框架中，很难在不重新启动应用程序的情况下在运行时处理依赖关系、停止/启动/卸载/安装功能。您使用自定义类加载器、关闭和启动挂钩等。
恕我直言，OSGI 以很小的成本为您提供了这种灵活性。
【讨论】：
尽管我是 OSGi 的忠实粉丝，但我会冒险NO。除非您正在使用其他 OSGi 捆绑包，或者您有一个特定问题，如果没有这个大锤，您将无法轻松解决。
好处是优雅的类路径分离（恕我直言）。如果您需要同一个 JAR/类的不同版本，比如说因为您在应用程序运行时升级了应用程序的某些部分，或者因为您正在组合许多第 3 方模块，那么 OSGi 就很棒。
这不是一件容易的事情，而且使用 OSGi 也不容易。它变得干净，但代价是环境堆栈中的另一层。还有很多工作需要学习和维护。
更不用说文档不是特别适合初学者。
我建议学习它——构建 Eclipse 插件是一种非常好的方法——但在你熟悉它之前不要将它构建到你的开发计划中。
【讨论】：