如何管理 OSGi 构建依赖项？
我们已将 OSGi 运行时 (Equinox) 嵌入到自定义客户端-服务器应用程序中，以方便插件开发，到目前为止一切进展顺利。 由于 Eclipse 内置的清单编辑器、依赖项管理和导出向导，我们一直使用 Eclipse 来构建插件。 使用 Eclipse 来管理构建不太有利于通过 Hudson 进行持续集成。
我们有依赖于其他 OSGi 包的 OSGi 包。 我真的不想在自定义 ANT 构建中硬编码构建顺序。 我们已经这么做了，这已经是过去式了，而且非常可怕。 是否有任何构建工具可以轻松管理 OSGi 依赖项（如果不能自动解决它们）？ 有没有任何不错的例子来说明如何做到这一点？
澄清：
生成的构建脚本只能通过 Eclipse 使用。 它们需要手动运行 Eclipse 的各个部分。 我们还有一些 Eclipse 构建不会有的标准目标，并且我不想修改生成的文件，因为我可能会重新生成（我知道我可以包含，但我想避免 Eclipse gen 文件全部 在使用 Eclipse PDE 时，每个插件都有一个 Manifest，但没有 build.xml ，
这是我的项目布局：
/
-PluginA
-PluginB
-PluginC
.
.
.
因为 PDE 为我做了这个。 很难用 Hudson 来自动化 GUI 驱动的流程。 我想设置我自己的 build.xml 来构建每个，但存在依赖性和构建顺序问题。 这些问题是由清单文件（描述 OSGi 导入）驱动的。 例如，PluginC 依赖于 PluginB，而 PluginB 又依赖于 PluginA。 它们必须按正确的顺序构建。 我意识到我可以手动控制构建顺序，我正在寻找一种工具来帮助自动化构建顺序依赖项管理。
We've embedded an OSGi runtime (Equinox) into out custom client-server application to facilitate plugin development and so far things are going great. We've been using Eclipse to build plugins due to the built-in manifest editor, dependency management, and export wizard. Using Eclipse to manager builds isn't very conducive to continuous integration via Hudson.
We have OSGi bundles which depend on other OSGi bundles. I'd really hate to hardcode build order in a custom ANT build. We've done this is the past and it's pretty horrible. Is there any build tool that can EASILY manage OSGi dependencies, if not automatically resolve them? Are there any DECENT examples of how to this?
CLARIFICATION:
The generated build scripts are only usable via Eclipse. They require manually running pieces of Eclipse. We've also got some standard targets which the Eclipse build won't have, and I don't want to modify the generated file since I may regenerate (I know I can do includes, but I want to avoid the Eclipse gen file all together)
Here is my project layout:
/
-PluginA
-PluginB
-PluginC
.
.
.
In using the Eclipse PDE, each plugin has a Manifest, but no build.xml as the PDE does that for me. Hard to automate a gui driven process w/ Hudson. I'd like to setup my own build.xml to build each, BUT there are dependencies and build order issues. These issues are driven by the Manifest files (which describe OSGi imports). For example, PluginC depends on PluginB which depends on PluginA. They must be built in the correct order. I realize that I can manually control the build order, I'm looking for a tool to help automate the build order dependency management.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
一路Maven2； 有一个名为 m2eclipse 的 Eclipse 插件来帮助管理它，准确解决依赖问题等等。 有免费在线书籍作为文档。
具体请参阅多模块项目，用于将许多组件捆绑在一起并具有 Maven确定构建顺序和依赖关系。
还有一个关于 Eclipse 集成的章节。
这只是 Eclipse 和 Maven，接下来您将获得 OSGi 的一些很棒的东西：
而且从根本上来说，Maven 模块模型与 OSGi 的捆绑模型完美契合。 三年多以来，我们一直在使用 Maven 构建和管理包含数百个捆绑包的多个产品，这非常棒。
Maven2 all the way; has an Eclipse plugin called m2eclipse to help with managing it, solves exactly the dependency problem and then some. Has a free online book as documentation.
Specifically look at multi-module projects for bundling many components together and have Maven work out the build order and dependencies.
There is also a chapter on the Eclipse integration.
And that is just Eclipse and Maven, next you get some cool goodies for OSGi:
And just fundamentally, the Maven module model fits perfectly with OSGi's bundle model. We've been building and managing multiple products with hundreds of bundles using Maven for more than 3 years now and it's great.
我们使用 Buckminster。 它是一个构建和组装框架，负责解决依赖关系、从各种存储库中获取、构建和打包产品。
这是一个 Eclipse 工具项目。 它与 PDE 集成良好。
这意味着我们用于构建 RCP 的所有元数据对于巴克明斯特解析和构建都是有用的。 例如，Manifest.MF、.product 中的 feature.xml 和 Require-Bundle 标头。
我们现在每个包中都没有任何构建脚本； 我们现在每个产品都有一个版本。 巴克敏斯特小心地遍历依赖图。
尽管他们（巴克明斯特团队）已经开始使用 Hudson 来托管该项目，但我们还是花了一点努力才让我们现有的巡航控制/蚂蚁系统与其一起工作。 我相信他们的构建设置也可供下载。
尽管它还处于起步阶段，但我们对它印象深刻。
我们还研究了 Pax-Construct 但我们不想使用 Maven。
我们目前也在研究 Spring DM 测试框架< /a> 增强单元测试工作。
We use Buckminster. It's a build and assembly framework, which takes care of the resolution of dependencies, the fetching from various repositories, building and packaging of the product.
It's an Eclipse Tools project. It integrates well with PDE.
This means that all the meta-data we use to build the RCP is useful to Buckminster to resolve and build. For example, feature.xml and the Require-Bundle header in the Manifest.MF, .product.
We haven't got any build scripts in each bundle now; we now have a single build per product. Buckminster takes care walking the dependency graph.
It took a little bit of effort to get our existing cruise-control/ant system working with it, though they (the Buckminster team) have started using Hudson to host the project itself. I believe that their build setup is also available for download.
We're really impressed with it, despite it's relative infancy.
We also looked into Pax-Construct but we didn't want to use Maven.
We're also currently looking at Spring DM testing framework to augment the unit testing effort.
借调 Maven2。 查看用于构建的 Tycho 插件 - 它们使用 Eclipse 的 JDT 编译器，因此它在编译时实现所有 OSGi 规则，就像 Eclipse 在运行时的方式一样。
另外，Apache Felix BND 插件似乎也很受欢迎。 我更喜欢 Tycho，因为它似乎更紧密地统一了 Maven 和 Eclipse 开发环境。
Seconding Maven2. Look into the Tycho plugins for building - they use Eclipse's JDT compiler so it implements all of the OSGi rules at compile-time, the same way Eclipse does at runtime.
Alternatively, the Apache Felix BND plugins also seem popular. I prefer Tycho because it more closely seems to unify the Maven and Eclipse development environments.
结束一些老问题...
由于缺乏网络连接和时间安排，我们的设置不利于 Maven。 我知道有离线 Maven 设置，但考虑到时间太多了。 希望当我们有时间重新组织构建过程时，我们能够使用正确的设置。
该解决方案涉及 Ant、BND 和一些自定义 Ant 任务。 各种捆绑包依赖项是手动管理的。 我们已经在使用 Ant； BND 和自定义任务将这一切联系在一起。 自定义任务只是确保我们的 bnd/eclipse 项目同步。
Closing out some old questions...
Our setup was not conducive to maven due to lack of network connectivity and timing. I know there are offline maven setups, but it was all too much given the time. Hopefully we'll get to use a proper setup when we've got time to reorganize the build process.
The solution involved Ant, BND, and some custom ant tasks. The various bundle dependencies are manually managed. We were already using Ant; BND and custom tasks tied it all together. The custom tasks just made sure our bnd/eclipse projects were in sync.
PDE 无头构建。 Eclipse 对此进行了详细记录。 如果您正在构建 Eclipse 插件，并且希望通过命令行来完成，那么 Eclipse PDE 无头构建就是您的最佳选择。
PDE Headless build. It's well documented by Eclipse. If you're building Eclipse plugins, and you want to do it via command line, The Eclipse PDE headless build is THE way to go.
我们使用 Hudson 结合 PluginBuilder 来构建基于 Eclipse 的 OSGi 包/插件。 这建立在 Eclipse 构建插件的标准 PDE 流程之上。 这意味着使用 Eclipse 作为编译器。
We use Hudson combined with PluginBuilder to build our Eclipse-based OSGi bundles/plugins. This builds upon Eclipse's standard PDE process for building plugins. This means using Eclipse as the compiler.
Maven 不需要互联网连接！ 看在上帝的份上，使用 -o 开关。
Maven does not require internet connectivity! Use the -o switch, for Christ's sake.
我使用 maven 3.0.2
mvn generated:archetype
参见 http: //felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
将您的依赖项添加到包中，使用 pom.xml 中的这个简短示例
或
I use maven 3.0.2
mvn generate:archetype
see http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
to add your dependencies into the bundle use this short example in the pom.xml
or