我们有一个很大的（约215个捆绑和计数）osgi（felix springdm）项目，使用maven和maven-osgi插件构建 .
我们用maven方式遇到了几个问题：
1.子模块pom必须继承父pom才能利用公共变量和依赖关系（没关系）但是父pom必须包含所有的包，以便能够一起构建所有内容 . 这种循环引用很难保持同步 .
2.子捆绑的单独版本是如此复杂，以至于（在我加入项目之前）决定对所有捆绑使用相同的版本 . 这意味着我们现在更新每个版本的所有捆绑包的版本，如果只是实际更改了它们中的一堆 . 这使得osgi的整个概念有点无意义恕我直言 . 请注意，我并不是说我们继续只触及少数捆绑包，我们会处理所有这些捆绑包，但每个版本通常都包含1或2个功能，这些功能只会影响一些捆绑包 .
3.为了完成包和最终工件的部署，我们还需要另一个子模块来导入部署所需的所有包（除了少数用于测试和模拟） . [编辑]请注意，这个聚合与主pom中的聚合不同，因为它不编译bundle而只是从maven存储库中选择它们 .
- maven依赖系统和osgi插件导入有时难以保持一致 . 忘记导入或放置错误的依赖关系太容易了 .
[编辑]在每个捆绑pom中有一个这样的部分：`
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>
</Export-Package>
<Import-Package>
com.google.gson,
org.apache.log4j,
org.apache.log4j.spi,
org.dom4j,
com.myinterfaces
</Import-Package>
</instructions>
</configuration>
</plugin>`
出于所有这些原因，我们还可以，但对maven并不十分满意 . 最近有人提议Gradle不是灵丹妙药，而是对当前形势的明确改进 .
你会建议搬到gradle吗？如果哪种方式最好？
有其他人遇到过同样的情况吗？我认为所有与Osgi的大项目都应该是共同的 .
免责声明：我寻找类似的问题：
Buildr, Gradle or wait for Maven 3?
Looking for a good dev environment for OSGi bundles
Maven : OSGI, bundles and multi-modules projects
但要么在哪里不关于osgi submodules或不关于gradle .
1 回答
您可以分离父maven模块和聚合maven模块，因为当前您的父pom有正确观察到的两个角色 . 更多信息可以在Maven Introduction to POM找到 .
我担心，除非你使用API Tools，否则捆绑版本管理不会变得容易 . 如果API工具可以作为Maven插件集成，那也许会很棒，但我不知道这方面的任何工作 . 因此，您可以立即触摸所有版本，也可以在每次需要时更新它们 . API Tools在这里会有很大帮助，但它仅适用于bundle，它可以作为Eclipse中的插件项目导入 .
那么，另一个聚合器模块会在这里提供帮助吗？您可以设置多个聚合器，这些聚合器聚合其他聚合器，因此您最终不会得到一个列出所有内容的巨大聚合器模块？因为您可能不想部署所有内容，所以可以设置要从部署中排除的内容 . 快速谷歌搜索显示如何做it .
@Neil Bartlett已经注意到，如果您正确设置了依赖关系，bnd将会处理您的清单 . 如果您需要额外调整默认值，您可以随时设置BND指令文件 .
您可以将Tycho放在可能的工具列表中 . 它将帮助您进行依赖关系管理，因为您只需要在Manifest中指定依赖关系，它将允许您使用API Tools（但尚未集成） . 但是，如果你想跳过一些令人头疼的问题，那么它将要求你使用p2存储库（直到Tycho改进了对依赖Maven工件的支持） .