【发布时间】:2010-11-19 00:19:51
【问题描述】:
我在我的应用程序中使用了一些现成的 OSGi 包,并希望将它们与尚不兼容 OSGi 的其他包重新打包到一个新包中。
EclipseLink 就是一个很好的例子,它可以作为多个 OSGi 包提供,其中大部分是可选的,具体取决于您想要做什么。我想挑选那些与我相关的包,添加数据库驱动程序(例如 MySQl JDBC 连接器)并将它们重新打包成一个更易于部署的新包。
我正在使用 Apache Felix 的 maven-bundle-plugin。我建立了一个没有源代码的新Maven项目,添加了四个eclipselink和mysql连接器作为依赖项并尝试了以下内容:
- 使用
<Embed-Dependency>和<Embed-Transitive>指令将所有依赖项包含在一个包中。问题:当插件重写清单时,需要来自 eclipselink 包的可选依赖项(例如 javax.mail.internet)。原始捆绑包在清单中包含“resolution=optional”,因此没有它也能正常工作。 - 使用插件的
manifest目标和jar-with-dependencies程序集,但这给了我基本相同的结果,只是需要更多的工作。 - 使用了插件的
bundleall目标,这不是我想要的,因为它再次创建了单独的包。更糟糕的是,因为现在这些包中没有它们的依赖项。
我将面临 Struts 2 的类似问题。我不会对此过于执着,只是使用一大堆单独的第三方捆绑包,但如果我可以更整齐地打包它们,我真的很想。我知道 OSGi 的一个重点是模块化,因此创建大包会破坏这一点,但我觉得如果你的模块无论如何都是紧密耦合的,你不妨将它们放在一个包中。
当然,我可以手动调整清单,但我绝对不想这样做。
【问题讨论】:
-
澄清一下,您想将一组 OSGi 包和其他 jar 的类、资源和清单内容合并为一个吗?您是否还需要公开非 OSGi jar 中的类型?
-
这不是违背OSGi的一般原则吗?为什么不 OSGify 非捆绑 jars(再次使用 bnd 和 maven)并将它们用作适当的捆绑依赖项而不是嵌入式依赖项。基本上,您将所有内容都转换为一个捆绑包。
-
@Rich Seller:是的,没错。实际上,与原始包相比,我需要公开的内容要少得多,而且我通常只需要来自非 OSGi jar 的一个包。例如,如果我将 eclipselink 和我的 db 驱动程序打包到一个包中,那实际上只需要导出 org.eclipse.persistence.jpa,其他一切都将在包中发生。
-
@omerkudat:我知道这一点,正如我在上面已经写过的。然而,即使您使用 OSGi 将所有内容模块化,在特定项目中,您也可能希望用一些模块化来换取更紧凑和更少混乱的包装。如果您不打算从 eclipselink 更改您正在使用的功能集,则无需拥有所有单独的捆绑包。将它们放在一个单独的中会更恰当地反映您的应用程序的实际模块化,因此更容易理解和维护。