我真的厌倦了一直在与 Maven 2 作斗争。构建工具不应该成为障碍。最近我一直在研究 Buildr 和 Gradle。Maven 3 似乎解决了一些问题。那么，我现在该怎么办？建造者？摇篮？还是等一年 Maven 3？
问问题
29285 次
9 回答
48
我不会对 Maven 3 期望太多。构建工具的 Maven 谱系背后的人一直认为项目构建是同质的，即：所有构建问题从根本上归结为同一个问题。面对相反的观点，这种世界观可以相当一致地持有，但要付出代价。Maven 中缺少脚本逻辑（“当你想编写脚本时，你知道自己做错了什么”）、繁琐的插件 API（“普通 Maven 用户不应该编写插件”）和中央存储库（“我们都具有相同的依赖关系”）都是这一总体假设的证明。
在现实世界中，构建问题是多种多样的，因为人们出于各种原因构建软件。它们都“发展”，就像我们偶尔“钻洞”一样，以解决独特的问题。无论您的抽象级别如何，在比较任意构建问题时，您总会发现相似之处。正是对这些相似之处的谴责和对差异的谴责是 Maven 设计的失败，也是它引起如此多抨击的原因。基本上，Maven 的前景是独裁和乌托邦式的。
PS：Maven有很好的特性，比如convention-over-configuration和使用repositories的想法（这个想法的Maven实现很麻烦）。
于 2010-01-12T17:03:31.280 回答
47
没有构建系统是灵丹妙药。我发现 Maven 解决的问题比它给我带来的问题要多，但是我很乐意编写插件来克服它的缺点，我也处理数百个项目，所以 Maven 的继承和依赖处理对我很有帮助。
稍微浏览一下，您会发现 Buildr 和 Gradle 也都存在问题（Ant 和 Ivy 也是如此），通常您正在用一组问题换另一组问题，这是寻找最不痛苦的情况。
关于 Maven，有什么特别困扰您的事情吗？还是一般的痒？如果这是一个特殊问题，值得查看Jira 上的 Maven 3 问题，如果问题没有得到解决，您可以提出它，否则您等待的意义可能不大
于 2009-08-20T14:33:05.517 回答
18
我们在这里使用 Maven，但我发现一旦脱离了一个简单的项目，pom.xml 就会开始变得越来越复杂。您开始花费大量时间研究如何配置您的 pom 以执行您想要的操作，以及如何解决各种问题。
真正吸引我的是我们正在建立的耳朵。我们在那个 ear 文件中有多个战争，而 Maven 通常将库放在战争中。但是，为了减小战争的大小，并保持 jar 相同，我们希望将战争之间共享的 jar 放在 ear 的 lib 目录中。
不幸的是，Maven 不能很好地处理这个问题。我们需要为每个 war 的 pom 手动配置它，然后将所有这些依赖项添加到 ear 的 pom.xml 中。
在另一个项目中，我们有基于 HTML 的帮助文件。编写帮助的人用 Microsoft Word 编写它们，然后使用程序将它们翻译成 HTML。单个字符的更改可以在数百个文件中产生反响。
为了解决这个问题，我们的帮助系统作为单个压缩文件存储在我们的源存储库中。当我们的文档团队创建一组新的帮助文件时，他们会将其压缩并替换存储库中的内容。
因此，我构建的一部分是解压缩此文件并将其放入战争中。在 Ant 中很容易做到，在 Maven 中无法做到，除非您使用 Antrun 插件，该插件允许您编写 Ant 代码来处理 Maven 在没有完整插件的情况下无法处理的问题。
我可以看到 Maven 在做什么，但理论领先于现实。我发现 Ivy 和 Ant 可以完成 Maven 所做的大部分依赖项检查，而无需编写和维护 pom 的所有问题。
如果您还没有使用 Maven，请先尝试使用 Ivy 的 Ant。然后，当 Maven 3 出现时，尝试一下。我记得从 Maven 1 到 Maven 2 的过渡。它们彼此完全不兼容，你使用 Maven 1 学到的任何东西都已经过时了。在 Maven 2 中学习和重做你的项目，突然发现自己在为 Maven 3 重做所有事情是很愚蠢的。
于 2010-06-02T16:17:27.920 回答
8
maven 3.x 已嵌入 IDE（至少在 netbeans 上，请查看此链接以获取更多信息）。您今天可以使用 maven 3.x 简单地使用 netbeans 构建一个 Maven 项目。
另一个好消息是 Maven 通过在 IDE 项目中集成 EJB/WS 获得了更多的“企业”支持（同样，至少在 netbeans 上）。
所以我会坚持使用 maven 2.x 进行生产构建并使用 maven 3.x 进行开发。
于 2009-08-20T14:58:10.467 回答
5
Maven 2 和 3 在各种项目中都非常适合我。我目前正在使用 Maven 3 alpha 7，它运行良好，尤其是与 Eclipse Maven 插件结合使用。
Maven 与 Ant 无缝集成 - 在两个方向上。在我当前的项目中，我们多次从 Ant 调用 Maven 以执行复杂的集成测试。同样，我们通过 Maven 的 AntRun 插件使用 Ant，我们还编写了自己的 Maven 插件。顺便说一句，这只是几分钟的事情，归结为编写一个带注释的 Pojo。
Maven 受到很多批评，因为许多开发人员不喜欢规则或约定。很简单，没有人强迫你使用 Maven。如果您想要最终的自由 - 无论如何 - 为您加入的每个项目重新编写自己的构建过程。但是，如果您喜欢创建软件而不是在每个项目上使用定制的构建过程重新发明轮子，请选择 Maven。
于 2010-03-27T18:17:01.263 回答
4
保持您的代码得到良好维护并分解为定义良好的模块，构建系统之间的移植成为一个小问题。
就目前而言，maven-2 是中间 2/3 项目的不错选择。对于真正简单的，蚂蚁仍然可以。对于真正复杂的，maven-2 和其他工具（如 antrun）的混合变得不可避免。
不知道为什么你在使用 maven-2 时遇到问题。
它与 ant 和 buildr 的不同之处在于它是一个描述构建过程的工具，而不是编写脚本。复杂的构建，具有多个动态部分和嵌套和/或瞬态依赖关系的构建很难构建，因为它们很难描述。
于 2009-08-20T16:18:20.177 回答
3
试试Lattice https://github.com/hackingspirit/Lattice 。我是作者。这是独家新闻：
在 Lattice 中，构建文件不是用 XML 编写的，而是用 Python 语言编写的。好处是更好的可读性和 Python 支持的强大的命令式构建脚本。对于多模块项目。Lattice 使用拓扑排序来决定构建每个模块的正确顺序。Lattice 还计划分析模块依赖关系以确定如何并行化模块编译。Lattice 的源代码非常精简，目前它由大约 500 行 Python 源代码组成。
于 2010-12-28T17:47:53.540 回答
2
我认为抱怨 Maven 的人应该花一些额外的时间来研究可用的插件。为了回应抱怨 Maven 僵化并且难以使用自定义构建逻辑/提供对构建过程的细粒度控制的评论 - 我建议查看 Maven 的 Ant 插件（实际上有几个，但这里有一个：http ://maven.apache.org/plugins/maven-antrun-plugin ）。多年来，我在使用它定制 Maven 构建方面取得了巨大成功。基本上，它允许您运行任何 Ant 命令作为 Maven 构建的一部分，并且您几乎可以使用 Ant 做任何事情；）
于 2012-05-14T18:46:06.320 回答
1
带有 Ivy 的 Ant 执行与 Maven 相同的依赖管理（实际上，它使用 Maven 的整个依赖管理基础设施，包括相同的 URL 存储库），但没有所有 POM 配置混乱。
对于那些真的不想使用 Maven 的人来说，Ant with Ivy 可能是一种处理依赖问题的方法。它解决了 Maven 应该解决的 90% 的问题。
于 2010-06-02T16:22:33.370 回答