【发布时间】：2011-05-10 00:11:29
【问题描述】：
出于什么原因，我想让我的项目成为一个 OSGI 包而不是一个标准的 JAR 包？仅当它被使用 OSGI 框架的应用程序（例如：Equinox/Eclipse）使用时才有意义？还是从开发的角度来看它也有用，即：能够在 Eclipse 开发期间轻松地被其他项目重用我的 OSGI 包？
【问题讨论】：
【发布时间】：2011-05-10 00:11:29
【问题描述】：
OSGIfying 一个项目将允许 OSGI 用于 Eclipse 中的依赖管理，而不是标准的 Eclipse 项目构建机制，或外部依赖管理工具，如 Ivy 或 Maven。将项目制作成 OSGI 包允许您将该项目的包依赖项表达为包依赖项（如果包依赖项存在包），它将由 OSGI 框架而不是那些其他机制（标准 Eclipse 项目 build/Ivy/Maven )。
标准 Eclipse 项目依赖项是通过在项目的构建路径上指定其他项目和库来建立的。转换为 OSGI 会将您的构建路径引用替换为 MANIFEST.MF import-package 或 required-bundles 声明。
使用 OSGI 进行依赖管理优于标准 eclipse 机制的优点是：
- 重新导出依赖项：您的包可以重新导出其依赖包，这意味着依赖于您的包的代码也不必依赖您的包的依赖项（如果它也使用它们）
- 版本管理：因此您可以指定依赖项的最小和最大预期版本。
另见Should I use Eclipse plug-ins (or OSGi Bundles) as a plain dependency management tool?
【讨论】：
如果您的项目是公共或开源库，那么请 将其设为 OSGi 包。这将对可能想要使用您的库的 OSGi 开发人员有很大帮助。
另一方面，如果您的库是私有的，那么 OSGifying 它的好处是有限的。大多数情况下，如果您决定以后有策略地采用 OSGi，这将是一个优势。您还可以从显式依赖中获得一些好处，即您可以查看捆绑包以准确确定它所依赖的内容。
这样做没有运行时成本。非 OSGi 运行时会简单地忽略清单中的 OSGi 数据。
作为构建步骤的一部分，您必须生成 OSGi 清单。最好的工具是 Bnd，它可以很容易地集成到任何 ANT 构建中——用它作为“JAR”任务的替代品。如果您使用 Maven 构建，请使用 Maven Bundle Plugin（内部使用 Bnd）。
【讨论】：
-
你应该把它打包成“bundle”还是只是有一个包含清单文件的“jar”？非 OSGI 开发人员可能更喜欢使用 jar 而不是 bundle。
-
为什么？一个包是一个JAR。
-
是的，你是对的，我虽然包装在 nexus 中会是“捆绑”，但事实并非如此。
-
太棒了。我知道 Maven 和 Nexus 有时喜欢假装一个包不是 JAR ......这并没有改变一个事实，即在物理上，一个包总是一个 JAR。
-
是的，唯一的区别是 META-INF/manifest.mf 中包含更多信息，对于不在 OSGI 环境中的人来说，这些信息将被忽略。我认为现在，所有 Apache 项目都是 OSGI-fied，然后他们会像你建议的那样发布捆绑包。
OSGi 提供对模块的支持，您可以控制依赖关系。每个模块可以包含和排除其他包中的包。您还可以在运行时替换捆绑包。将整个项目制作成单个捆绑包没有这些好处。如果它不能作为 OSGi 包提供，我只会将像 jdbc 驱动程序这样的 jar 包装为包。 首先检查您的项目是否有好处。然后确定哪些模块应该是一个捆绑包。
【讨论】：
这只有在你提到的 OSGi 容器中使用时才有用。
如果您正在寻找关于为什么它通常有用的答案，您可以通过谷歌搜索找到很多 - 从维基百科开始：
总的来说，我想说 OSGi 的主要好处是封装/版本控制、解决 JAR 地狱和框架提供的管理，这取决于您的项目，您可能感兴趣也可能不感兴趣。
如果您还没有阅读过 OSGi，我绝对建议您阅读一下 - 这是非常有趣的技术。我建议阅读 Neil Bartlett 在 EclipseZone 上的文章 - 这是第一篇：
它们有很多，所以用谷歌搜索它们 - 非常有趣的读物，它也会让你知道这是否是你应该考虑的事情。
SpringSource 是 OSGi 的大力支持者，因此也值得一看：
【讨论】：
如果您打算在 OSGi 上下文中使用它，那么您不妨将它做成一个捆绑包。我不知道把它做成一个捆绑包有什么负面影响，而如果你不把它做成一个捆绑包，后来发现你需要它，那么你可能不得不回去修复它。除此之外，除了使用清单元信息的 OSGi 之外，我个人不知道其他任何东西——但就像我说的那样；我觉得不会痛。
【讨论】：