为什么要让我的项目成为 OSGI 包而不是标准 JAR 包？
出于什么原因，我希望将我的项目制作为 OSGI 捆绑包，而不仅仅是标准 JAR 包？仅当它由使用 OSGI 框架（例如：Equinox/Eclipse）的应用程序使用时才有意义吗？或者从开发的角度来看它也很有用，即：在 Eclipse 开发期间能够轻松地由其他项目重用我的 OSGI 包？
For what reasons would I want to make my project an OSGI bundle as opposed to just a standard JAR package? Does it only make sense if it is going to be used by an application that uses an OSGI framework (eg: Equinox/Eclipse)? Or is it also useful from a development point of view, ie: being able to easily reuse my OSGI bundle by other projects during Eclipse development?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
OSGi提供了对模块的支持，你可以控制依赖关系。每个模块可以包含和排除其他捆绑包中的包。您还可以在运行时替换捆绑包。将整个项目做成一个捆绑包并没有这些好处。如果 jdbc 驱动程序之类的 jar 不能作为 OSGi 捆绑包提供，我只会将其包装为捆绑包。
首先检查您的项目是否会带来好处。然后确定哪些模块应该是一个捆绑包。
OSGi provides support for modules, you could control the dependencies. Each module may include and exclude packages from other bundles. You can also replace bundles during runtime. Making a whole project a single bundle has none of these benefits. I would only wrap a jar like a jdbc driver as bundle if it is not available as an OSGi bundle.
First check whether your project would have a benefit. Then identify which modules should be a bundle.
如果您的项目是公共或开源库，那么请将其设为 OSGi 捆绑包。这对于可能想要使用你的库的 OSGi 开发人员来说会有很大的帮助。
另一方面，如果您的库是私有的，那么对其进行 OSG 化的好处是有限的。大多数情况下，如果您稍后决定战略性地采用 OSGi，这将是一个优势。您还可以从显式依赖项中获得一些好处，即您可以查看捆绑包以准确找出它所依赖的内容。
这样做没有运行时成本。非 OSGi 运行时会忽略清单中的 OSGi 数据。
作为构建步骤的一部分，您必须生成 OSGi 清单。用于此目的的最佳工具是 Bnd，它可以轻松集成到任何 ANT 构建中 - 使用它作为“JAR”任务的替代品。如果您使用 Maven 进行构建，则使用 Maven Bundle Plugin（内部使用 Bnd）。
If your project is a public or open source library, then please do make it an OSGi bundle. This will be of great help to OSGi developers who may want to use your library.
On the other hand if your library is private then the benefits of OSGifying it are limited. Mostly it will be an advantage if you decide to adopt OSGi strategically later. You may also derive some benefit from the explicit dependencies, i.e. you can look into the bundle to work out exactly what it depends on.
There is no runtime cost of doing this. The OSGi data in the manifest is simply ignored by non-OSGi runtimes.
You will have to generate the OSGi manifest though as part of your build step. The best tool to use for this is Bnd, which can be easily integrated into any ANT build -- use it as a replacement for the "JAR" task. If you are building with Maven, then use the Maven Bundle Plugin (which uses Bnd internally).
正如您所提到的，仅当要从 OSGi 容器中使用它时，这才有用。
如果您正在寻找为什么它通常有用的答案，您可以通过谷歌搜索找到很多东西 - 从维基百科开始：
总的来说，我认为 OSGi 的主要好处是封装/版本控制、解决 JAR 地狱以及框架提供的管理，这可能会也可能不会根据您的项目，您会感兴趣。
如果您还没有阅读过 OSGi，我强烈建议您阅读一下 - 这是非常有趣的技术。我建议阅读 Neil Bartlett 关于 EclipseZone 的文章 - 这是第一篇：
其中有很多，所以用谷歌搜索它们 - 非常有趣的阅读，这也会让您知道这是否是您应该考虑的事情。
SpringSource 是 OSGi 的大力支持者，因此也值得一看：
This is useful only if it's going to be used from within an OSGi container as you mentioned.
If you are searching an answer on why it is useful in general is something you can find a lot just by googling - start from Wikipedia:
In general, I'd say OSGi's main benefits are encapsulation/versioning, solving JAR hell and management provided by the framework, which may or may not be interesting to you depending on your project.
I definitively suggest reading about OSGi if you haven't already - it's very interesting technology. I would suggest reading Neil Bartlett's articles on EclipseZone - this is the first one:
There are a bunch of them, so google them - very interesting read, which will also give you an idea whether this is something you should consider.
SpringSource is a big proponent of OSGi, so it's worth taking a look there, too:
如果您计划在 OSGi 上下文中使用它，那么您不妨将其打包。我不知道将其作为捆绑包会产生任何负面影响，而如果您不将其捆绑并稍后发现您需要它，那么您可能必须返回并修复它。除此之外，我个人不知道除了 OSGi 之外还有其他使用清单元信息的东西 - 但就像我说的；我认为这不会伤害。
If you ever plan on using it in an OSGi context then you might as well make it a bundle. I don't know that there are any negative affects to making it a bundle, whereas if you don't make it a bundle and find out later on that you need it to be then you may have to go back and fix it. Aside from that I personally don't know of anything other than OSGi which uses the manifest meta information - but like I said; I don't think it will hurt.
OSGIFing 项目将允许在 Eclipse 中使用 OSGI 进行依赖关系管理，而不是使用标准的 Eclipse 项目构建机制或外部依赖关系管理工具（例如 Ivy 或 Maven）。将项目制作成 OSGI 捆绑包允许您将该项目的包依赖项表达为捆绑包依赖项（如果包依赖项存在捆绑包），这将由 OSGI 框架而不是其他机制（标准 Eclipse 项目构建/Ivy/Maven）处理）。
标准 Eclipse 项目依赖项是通过在项目的构建路径上指定其他项目和库来建立的。转换为 OSGI 会将构建路径引用替换为 MANIFEST.MF 导入包或必需捆绑包声明。
与标准 Eclipse 机制相比，使用 OSGI 进行依赖关系管理的优点是：
另请参阅 我应该使用 Eclipse 插件（或 OSGi Bundles）作为简单的依赖管理工具？
OSGIfying a project will allow OSGI to be used for dependency management in Eclipse instead of the standard Eclipse project build mechanism, or an external dependency management tool such as Ivy or Maven. Making a project into an OSGI bundle allows you to express that project's package dependencies as bundle dependencies (if a bundle exists for the package dependency) which will be handled by the OSGI framework instead of those other mechanisms (standard Eclipse project build/Ivy/Maven).
Standard Eclipse project dependencies are established by specifying other projects and libraries on your project's build path. Converting to OSGI would replace your build path references with MANIFEST.MF import-package or required-bundles declarations.
Advantages of using OSGI for dependency management over the standard eclipse mechanism are:
See also Should I use Eclipse plug-ins (or OSGi Bundles) as a plain dependency management tool?