从 maven 切换到 gradle 来管理一个 osgi 大项目（>200 个捆绑包）答案

【问题标题】：switching to gradle from maven to manage a osgi big project (>200 bundles)从 maven 切换到 gradle 来管理一个 osgi 大项目（>200 个捆绑包）
【发布时间】：2011-09-08 07:29:22
【问题描述】：

我们有一个很大的（约 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 的大型项目。

免责声明：我寻找过类似的问题，例如：

Buildr, Gradle or wait for Maven 3?

Looking for a good dev environment for OSGi bundles

Maven : OSGI, bundles and multi-modules projects

但是在哪里不是关于 osgi 子模块或不是关于 gradle。

【问题讨论】：

我像鹰一样看这个问题。我们将很快将一个类似的大型软件移植到 OSGi，并且已经具有复杂的依赖关系。所以我在这里祈祷银弹:)
我很好奇您的第 4 点。您没有明确说明，但听起来您正在使用 maven-bundle-plugin，它在内部使用 bnd 生成 MANIFEST.MF。在那种情况下，为什么需要手动维护导入？由于 bnd 通过分析您的字节码来生成 Import-Package 语句，因此基本上不可能“忘记导入”。 Bnd 也可能会改善您的版本管理...
是的，我们使用的是 maven-bundle-plugin，我用一个例子编辑了这个问题。
嗨 Uberto，刚刚回到这个问题。我注意到您的 POM 包含显式 Import-Package 语句，它覆盖了 bnd 对依赖项的自动检测。你为什么这么做？如果您让 bnd 生成此信息，生活会轻松很多。
我今天也有同样的问题。 Uberto，一年多过去了，你有没有切换到 Gradle，那么，现在情况好些了吗？

标签： java maven osgi apache-felix cradle

【解决方案1】：

您可以将父模块和聚合 maven 模块分开，因为当前您的父 pom 具有您正确观察到的两个角色。更多信息请访问Maven Introduction to POM。
恐怕除非您使用API Tools，否则bundle 版本管理不会变得更容易。如果 API 工具可以集成为 Maven 插件，也许会很棒，但我不知道这方面有什么工作。因此，您要么一次触摸所有版本，要么在每次需要时更新它们。 API 工具在这里会有很大帮助，但它仅适用于捆绑包，可以在 Eclipse 中作为插件项目导入。
那么，另一个聚合器模块会在这里提供帮助吗？您可以设置多个聚合器，它们聚合另一个聚合器，这样您最终不会得到一个列出所有内容的巨大聚合器模块吗？因为，您可能不想部署所有内容，您可以设置要从部署中排除的内容。快速谷歌搜索显示如何做it。
@Neil Bartlett 已经指出，如果您正确设置了依赖项，bnd 将处理您的清单。如果您需要对默认值进行额外调整，您可以随时设置 BND 指令文件。

您可以将 Tycho 放入可能的工具列表中。它将帮助您管理依赖项，因为您只需要在清单中指定您的依赖项，它将允许您使用 API 工具（但还没有集成）。但是，如果您想跳过一些令人头疼的问题，它将要求您使用 p2 存储库（直到 Tycho 改进了它们对依赖于 Maven 工件的支持）。

【讨论】：

感谢您设置多个聚合器的建议。我也会看看 API Tools 和 Tycho。