构建允许在不同二进制文件之间共享模块的系统答案

【问题标题】：Build system that allows sharing modules amongst different binaries构建允许在不同二进制文件之间共享模块的系统
【发布时间】：2010-12-26 07:52:46
【问题描述】：

我正在尝试选择最适合在企业中使用公共源代码库的构建系统，并强调公共代码的共享。我希望源层次结构看起来像这样：

- 源代码 - 爪哇 - 常见的 - 网 - 数据库 - 团队1 - 团队2 - 团队3 - 库 - 测试 - 爪哇 - 常见的 - 网 - 数据库 - 团队1 - 团队2 - 团队3 - 库

我们的目标是建立一个构建系统，团队[1-3] 可以在其中拥有明确指定其依赖关系的独立构建。依赖项可能如下所示：

- 团队1 - 普通/网络 - 团队3/lib - 团队2 - 通用/数据库 - 团队3

因此，例如，team1 的构建将包括 team1、common/net 和 team3/lib 中的所有内容；但没有别的。理想情况下，测试将以相同的方式集成（测试 team1 将为 team1、common/net 和 team3/lib 运行测试）。

我目前正在使用 Ant，但还没有找到一种明智的方法来管理这样的层次结构。我开始关注 Maven 2 管理依赖层次结构的能力，但它似乎希望每个模块都有完整的项目。这不是问题，但它似乎迫使我进入一个不能很好地映射到传统 java 包层次结构的目录结构。似乎我可以使用 alternative layout 对 buildr 做我想做的事情，但我担心这可能会变得脆弱。

有人可以推荐一些对我有用的东西吗？

【问题讨论】：

标签： java maven-2 build buildr

【解决方案1】：

我认为你实际上有三个问题。

如何布局您的项目以使工件有意义。
如何最好地为每个项目处理这些工件的共享。
如何在将开发团队转换为使用新项目结构的同时处理生产力损失。

对于第一个问题，尽可能使用 Maven 约定并将项目组织成多个工件。如果工件应该嵌套在父级下，请这样做。从最简单的没有依赖关系的工件开始，然后按照自己的方式编写代码。

我不确定您为什么认为布局不支持传统的 Java 层次结构？它应该可以工作，尤其是如果您使用父 pom。

显然，根据您处理第一个问题的方式，第二个问题可能会变得非常少。我宁愿创建更多的工件而不是更少，并使用像 Nexus 或 Artifactory 这样的存储库管理器来管理它们。至少这样，您的团队的构建可以依赖预先构建和测试的 jar，方法是访问您的存储库以获取他们正在使用的 jar 的最新 SNAPSHOT 或 RELEASE。

第三，确保您使用的是支持 Maven 的 IDE。如果您在使用诸如 Rational Application Developer 7.0.x 之类的东西或基于低于 Eclipse 3.4 的 IDE 时遇到困难，那么您将无法使用 M2Eclipse 插件。如果没有 M2Eclipse，开发人员将不得不跳过一些不理想的手动操作。 Netbeans 6.7 和 6.8 具有非常好的 Maven 支持。

【讨论】：

maven-eclipse-plugin 工作得很好，如果你不能使用 m2eclipse，它是一个相当不错的选择。

【解决方案2】：

正如您所说，Maven 2 是您案例的首选选项。 Maven 文件夹结构不是强制性的——它是可配置的，如果你认为它不合适的话。但是，我认为这是一个很好的结构，您可以毫无悔意地遵循。

您可以使用repository manager，这样使用某些依赖项的人就不必检查他们所依赖的项目。

【讨论】：

【解决方案3】：

我开始关注 Maven 2 管理依赖层次结构的能力，但它似乎希望每个模块都有完整的项目。

这是一种方法。或者，一个多模块的 Maven 项目可以这样组织：

project
    module-1
        src
            main
                ....
            test
                ....
        pom.xml
    module-2
        src
            main
                ....
            test
                ....
        pom.xml
    ...
    pom.xml

每个 pom.xml 还可以引用其他树定义的模块。顺便说一句，Eclipse maven 插件支持这种方法以及更常见的每个项目一个模块的方法。

【讨论】：

这实际上是我想避免的，我可以看到当我尝试嵌套模块时会变得非常丑陋（比如如果“数据库”有 mysql 和 postgres 子目录）。
@Bill，使用 Maven2 设置，情况并非如此......该项目将引用“mysql”和“postgres”，但不包含这些组件源代码的副本；相反，构建会导致下载并链接 JAR 库依赖项。
@Bill - 美丽（或者在这种情况下是丑陋）在旁观者的眼中。真正重要的是您/您的同事能否找到文件。

【解决方案4】：

我目前正在使用 Ant，但还没有找到一种明智的方法来管理这样的层次结构。

这令人惊讶，因为 Ant（+Ivy？）为您提供了所需的所有灵活性。

我开始关注 Maven 2 管理依赖层次结构的能力，但它似乎希望每个模块都有完整的项目。

如果您的意思是每个模块一个 pom.xml，那么这是正确的。

这不是问题，但它似乎迫使我进入一个不能很好地映射到传统 java 包层次结构的目录结构。

是的，Maven 带有一些约定，项目目录结构就是其中之一。虽然这是（有点）可配置的，但我认为您无法匹配所需的布局（将测试和源代码放入单独的层次结构中）。实际上，如果你选择 Maven，我强烈建议使用默认值，你应该采用它的理念，它会为你节省很多，真的很多，痛苦（更不用说一些插件可能以硬编码的方式使用这些默认值）。

说实话，我不太明白您所说的不能很好地映射到传统 java 包层次结构的目录结构是什么意思。首先，Maven 非常适合 Java，所以这对我来说没有任何意义。其次，这可能更主观，您的布局（带有分离的测试和源代码树）在我看来一点也不传统。也许您应该澄清一下传统的确切含义...

似乎我可以使用替代布局对 buildr 做我想做的事情，但我担心这可能会变得脆弱

我不太了解 buildr，所以我不能说太多，但我知道它确实更灵活。也就是说，如果 Ant 在灵活性方面不能让您满意，那么我不明白为什么 buildr 会更好。

不要忘记，与 Maven 相比，builder 和 Ant+Ivy 的社区要小得多。不要小看这一点，这可能会成为一个真正的问题。

就个人而言，我会选择 Maven 并重新考虑您的布局。但是假设我有偏见。

【讨论】：

关键是我想支持细粒度级别的代码共享（低至java包）。因此，我希望模块的创建和细分尽可能轻松。关于“传统的 java 包层次结构”，我的意思是我想浏览存储库，感觉就像你正在经历一个巨大的 java 项目......而实际上构建系统只使用每个所需的部分构建。
Maven 使模块的创建变得非常容易，但我不建议创建太细粒度的模块，而且我认为没有必要进入包级别。我稍后会更新我的答案以涵盖这一点。

【解决方案5】：

从长远来看，您要做的事情会给您带来很多麻烦...每个独立组件都应该真正地制作成具有自己存储库的自己的项目，否则，您可能会遇到很多问题一个组件的更改会破坏其他组件并且更新时间过长。我强烈建议您将每个组件都放到自己的项目中，并使用 Maven2 来构建。

【讨论】：

【解决方案6】：

您可以使用 Buildr 来完成。你可以忍受它一段时间。

当然，像线程上的大多数人一样，我宁愿不推荐这种方法。您还可以使用 base_dir 更改项目的基本目录。

【讨论】：