从 Maven 切换到 gradle 来管理 osgi 大项目（>200 个包）
我们有一个很大的（~215 个包并且还在增加）osgi (felix+springdm) 项目，使用 maven 和 maven-osgi 插件构建。
我们在使用 maven 方式时遇到了几个问题：
1. 子模块 pom 必须从父 pom 继承才能利用公共变量和依赖项（没关系），但是父 pom 必须包含所有包 pom 才能将所有内容构建在一起。这种循环引用使得保持所有同步变得非常困难。
2.子捆绑包的单独版本控制非常复杂，以至于决定（在我加入该项目之前）对所有捆绑包使用相同的版本。这意味着我们现在会更新每个版本的所有捆绑包的版本，即使实际上只有其中一些捆绑包发生了更改。恕我直言，这使得 osgi 的整个概念有点毫无意义。请注意，我并不是说我们会继续只涉及少数捆绑包，我们会处理所有捆绑包，但每个版本通常包含 1 或 2 个功能，这些功能仅影响某些捆绑包。
3. 为了打包和部署最终的工件，我们还需要另一个子模块来导入部署所需的所有包（除了一些测试和模拟之外的所有包）。 [编辑] 请注意，此聚合与主 pom 中的聚合不同，因为它不编译捆绑包，而只是从 Maven 存储库中选取它们。
4. maven 依赖系统和 osgi 插件导入有时很难保持一致。忘记导入或放置错误的依赖项太容易了。
[编辑] 在每个bundle 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 的所有大型项目来说这应该是常见的。
免责声明：我寻找了类似的问题，例如：
但是要么 where where 与 osgi 子模块无关，要么与 gradle 无关。
We have a big (~215 bundles and counting) osgi (felix+springdm) project, build with maven and maven-osgi plugin.
We've several problems with maven way:
1. submodules pom have to inherit from parent pom to take advantage of common variables and dependencies (that's ok) but then parent pom has to include all bundles pom to be able to build everything in together. This kind of circular reference makes much hard to keep all in sync.
2. the individual versioning of subbundles was so complex that it was decided (before I joined the project) to use the same version for all bundles. This means we now update version of all bundles for every release also if just a bunch of them are actually changed. This makes the whole concept of osgi a bit meanless IMHO. Please note that I'm not saying we continue to touch just a minority of bundles, we work on all of them but every release usually contains 1 or 2 features, that affects just some bundles.
3. to do the package and the deploy of the final artifact we need still another submodule that imports all the bundles needed for the deploy (all but a few for tests and mocks).
[edited]
Note that this aggregation is different from the one in the main pom as it doesn't compile bundles but just pick them from the maven repository.
4. the maven dependency system and the osgi plugin imports are sometimes hard to keep aligned. It's just too easy to forget an import or putting a wrong dependency.
[edited]
In every bundle pom there is a section like this:
`
<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>`
For all those reasons, we are ok but not perfectly happy with maven. Recently someone proposed Gradle not as a panacea but as a definite improvements over the current situation.
Would you recommend moving to gradle? and in case which would be the best way?
Has someone else experienced the same situation? I think it should be common for all big projects with Osgi.
Disclaimer: I looked for similar questions like:
Buildr, Gradle or wait for Maven 3?
Looking for a good dev environment for OSGi bundles
Maven : OSGI, bundles and multi-modules projects
but either where where not about osgi submodules or not about gradle.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以将第谷放入可能的工具列表中。它将帮助您进行依赖项管理，因为您只需在清单中指定依赖项，并且它将允许您使用 API 工具（但尚未集成）。然而，如果您想跳过一些令人头疼的问题，它将要求您使用 p2 存储库（直到 Tycho 改进了对依赖 Maven 工件的支持）。
You can put Tycho in the list of possible tools. It will help you with the dependency management, because you need to specify your dependencies in the Manifest only and it will permit you to use API Tools (but no integration yet). It will however require that you use p2 repositories if you want to skip some headaches (until Tycho has improved their support for depending on Maven artifacts).