当我第一次开始查看OSGi时，我的印象是你可以构建一个JAR，只要它有一个清单文件，你可以将它部署在OSGi容器中。我想象以经典的方式构建我的模块（maven），并且可能使用一些插件或类似的东西来编写清单，然后我可以拥有我的模块，它基本上是一个独立的应用程序通过OSGi与其他模块通信。
关于OSGi的进一步阅读，我开始看到更多的例子，它被用于更低级别，基本上取代了依赖注入，并提供了诸如日志记录等交叉关注服务。似乎使用像hibernate或其他的东西，这是一个问题...（或者我可能只是遗漏了一些东西）。
至少对我而言，我并没有真正意识到拥有如此优秀的模块化水平和与OSGi的集成，我宁愿拥有一个单独的模块，每个模块都有自己的一套技术和框架，可能还有Web资源和持久层。这可以通过OSGi实现吗？如果是的话，你能指出我正确的方向，例子等吗？
编辑，添加了一些有关我如何使用OSGi的详细信息：
我只是想到拥有一个多级模块的可能性，可能会有更高层次的责任。
喜欢说议程模块。在这种情况下，我希望拥有诸如事件的持久性，添加事件，使用过滤器列出事件等等... 这个议程可能有几个内部类，甚至可能需要一个持久层。所以我想使用类似Guice的东西去DI那些类，以及一些JPA来保存我的数据。
我可以理解，像服务器或日志记录这样的X-cutting问题可以有一个捆绑包，但数据模型特定于议程包。所以我认为我的问题到底是什么，什么是不可能在一个包内做？内部应该和不应该做什么？
谢谢！ 毛
答案 0 :(得分：2)
您可以使用OSGi而不强制在应用程序代码上对OSGi进行任何依赖。但是，由于OSGi提供了模块化，因此中间件（您的层）需要具备一些OSGi知识。问题在于，在模块化世界中，您希望隐藏实现细节，这就是整个目的。但是，像Spring和Hibernate这样的东西倾向于假设类路径没有边界，并且它们会进入栅栏。幸运的是，越来越多的中间件正在为此做好准备，我听说Hibernate现在已经付出了努力，而OSA也可以使用JPA。
答案 1 :(得分：2)
对于很多人来说OSGi是很多东西，你几乎可以选择你想要使用的部分：
依此类推 - 只需使用您感到舒适的水平。
另一方面，如果你想做web应用程序，你真的需要考虑OSGi，你使用的库，应用程序管理器和servlet / jee /任何容器之间的架构相互作用。 OSGi将驻留在什么级别？一般来说，有OSGi-> container-＆gt; app，container-＆gt; OSGi-＆gt; app和container-＆gt; app-＆gt; OSGi解决方案，每个都有自己的特性。
答案 2 :(得分：1)
关于使用maven构建，您可以使用Maven-Bundle-Plugin帮助您构建OSGi包，而无需自己编写清单。所有必需的元信息都将在您的POM中。
可以在模块层之上实现依赖注入。一种可能的解决方案是 Declarative Services ，它允许您通过XML描述或代码注释进行注入。它强烈反映了OSGi服务的动态特性（动态绑定解绑服务）。 替代方案是 Blueprint ，它基于spring并具有非常相似的语法。一个关键特性是它可以抽象出绑定和解除绑定服务的本质。如果您考虑使用Spring，请使用Blueprint。
OSGi仅暗示您如何构建模块。你得到一个定义良好的模块交互图（谁导入/导出一个包？谁导出服务和谁使用它？） 因此，您可以通过为每项任务构建一致的捆绑包来构建企业架构。
答案 3 :(得分：1)
OSGi有时被称为JVM的面向服务的体系结构。将捆绑包视为提供服务的模块化单元有助于定义正确的粒度：您通常会拥有API捆绑包，这些捆绑包仅用于提供定义API的Java包，提供这些API实现的服务包以及提供的实用程序/辅助包你提到的跨领域服务。
您可以在OSGi之上使用一些依赖注入框架，但根据我的经验（使用Apache Sling和Adobe CQ5）保持简单通常会更好。 OSGi服务组件运行时和配置管理提供了管理服务，依赖项和配置所需的全部功能，尤其是从一开始就为您设计系统时。
您可以在http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches-2012-short-form-edition的“OSGi战壕故事”幻灯片中找到更多关于OSGi设计Adobe CQ5的经验 - 这可能有助于更好地了解OSGi如何用于建筑群系统