为什么Maven的表现这么差？[关闭]

互联网上有很多关于Maven不好的话题。几年来，我一直在使用Maven的某些功能，我认为最重要的好处是依赖管理。

Maven文档还不够用，但是通常当我需要完成某件事时，我先弄清楚它然后再起作用（例如，当我实现对jar的签名时）。我不认为Maven很棒，但是它确实解决了一些问题，没有这些问题将是真正的痛苦。

那么，为什么Maven的表现如此差劲，我将来会遇到Maven哪些问题？也许还有我不知道的更好的选择？（例如，我从未详细研究过常春藤。）

注意：这不是尝试引起参数。这是清除FUD的尝试。

大约六个月前，我调查了Maven。我们正在启动一个新项目，没有任何遗产可支持。说：

• Maven要么全有要么全无。或至少据我所知。您不能轻易将maven用作ant的替代品，并逐渐采用更高级的功能。
• 根据文档，Maven是超然的幸福，它使您所有最疯狂的梦想成真。在您被启发之前，您只需要思考手册十年。
• Maven使您的构建过程取决于您的网络连接。
• Maven有无用的错误消息。比较ant的“项目y中不存在目标x”与mvn的“无效任务'运行'：您必须指定一个有效的生命周期阶段，或以plugin：goal或pluginGroupId：pluginArtifactId：pluginVersion：goal格式指定目标”它建议我使用-e运行mvn以获取更多信息，这意味着它将打印相同的消息，然后显示BuildFailureException的堆栈跟踪。

以下是我对Maven的不满意的大部分摘录，摘录自《 Better Builds with Maven》：

当某人想知道Maven是什么时，他们通常会问“ Maven到底是什么？”，并且他们会期望得到简短的，咬一口的答案。“它是构建工具还是脚本框架”，Maven是三个以上无聊，毫无启发的词。它是思想，标准和软件的组合，并且不可能将Maven的定义提炼为简单的摘要。革命性的想法通常很难用言语传达。

我的建议是：如果您无法用文字传达想法，则不应尝试写关于该主题的书，因为我不会心态吸收这些想法。

• 它从一开始就为您强加了刚性结构。
• 它基于XML，因此像ANT一样难以阅读。
• 它的错误报告晦涩难懂，一旦出现问题，您就会陷入困境。
• 该文档很差。
• 它使困难的事情变得容易，而使简单的事情变得困难。
• 维护Maven构建环境要花费太多时间，这使拥有单一系统的构建系统无法实现。
• 需要很长时间才能确定您在maven中发现了一个错误，并且没有配置错误。这些错误确实存在，并且在令人惊讶的地方。
• 它许诺了很多，但背叛了你，就像一个美丽而诱人，但在情感上却冷酷而可操纵的情人。

过去我肯定对Maven感到bit之以鼻。但是现在，我不会没有它。我觉得好处远远超过任何问题。主要：

• 标准化的项目结构。
  • 假设有一个新的开发人员加入了一个项目：
    • 当您说这是一个Maven项目时，开发人员就会知道项目布局以及如何构建和打包项目
    • 当您说这是一个Ant项目时，开发人员将不得不等待您进行更多解释，或者必须通过build.xml来解决问题。
  • 当然，总是可以在Ant上强加公司范围内的标准，但是我认为，您经常会重新发明众所周知的轮子。
• 依赖管理。
  • 不仅具有外部库，而且具有内部库/模块。确保使用Nexus或Artifactory等Maven存储库代理服务器。
  • 可以使用Ivy来做一些这样的事情。实际上，如果您只需要依赖管理，那么使用Ivy可能会更好。
• 特别是在项目中。我发现分解小的子项目非常有用，而maven很好地处理了这个问题。使用蚂蚁要困难得多。
• 标准化的工件管理（尤其是与联系或工件结合使用时））
• 发布插件很棒。
• Eclipse＆NetBeans集成非常好。
• 与哈德森的融合非常棒。特别是诸如findbug之类的趋势图。
• 这是一个小点，但事实上，类似的版本号Maven的嵌入功能细节里面默认的罐子或战争（不只是在文件名）是极其有帮助的。

我的主要缺点是：

• 命令行非常无益。首先，这让我受益匪浅。
• XML格式非常冗长。我知道为什么这样做了，但是阅读仍然很痛苦。
  • 也就是说，它具有XSD，可在IDE中轻松进行编辑。
• 一开始很难让您转过头来。例如，生命周期之类的事情。
  • 权威的maven指南是一个很好的介绍。

我真正相信，花一点时间来了解Maven是值得的。

我从两个大型项目中获得的实践经验是，我们为每个项目花费了1000-1500小时来解决与Maven相关的问题，不包括从Maven 1迁移到Maven 2的500小时工作量。

从那时起，我必须说我绝对讨厌行家。考虑这个问题时，我感到沮丧。

Eclipse集成非常糟糕。（例如，我们在代码生成方面遇到了无数麻烦，例如，eclipse经常无法与生成的代码同步，并且需要完全重新构建。怪罪既是maven又是eclipse，但是eclipse比maven更有用，并且说emacs，所以蚀停留和行家必须走。）

我们有很多依赖关系，并且正如我们发现的那样，语法错误实际上经常发生在公共Maven存储库中，这可能会浪费您宝贵的时间。每周。解决方法是拥有一个代理或本地控制的存储库，并且花了很多时间才能正确使用。

Mavens项目结构实际上并不适合使用Eclipse进行开发，因此Eclipse中的构建时间会增加。

由于代码生成和同步问题的影响，我们不得不从零开始进行重新构建，从而将您的代码/编译/测试周期减少到无穷无尽的编译/ websurf / sleep / die /代码周期，将您带回到90年代， 40分钟的编译时间。

Maven的唯一借口是依赖关系解析，但我想偶尔这样做，而不是在每个版本中都这样做。

综上所述，maven尽可能远离KISS。而且，提倡者往往是那种在他们的生日是素数时在生日上额外庆祝的人。随意对我投反对票:-)

Maven很棒。我认为，其声誉之所以与陡峭的学习曲线有关。（我终于快要结束了）

该文档有点麻烦，只是因为感觉在开始变得有意义之前，似乎需要理解许多文本和新事物。我说，时间是使Maven得到广泛赞誉所需的一切。

因为Maven是一种减少成年男子抽泣绝对恐怖的装置。

优点：

• 依赖管理。几年来，我和我的同事们一直没有手动下载和管理依赖项。这可以节省大量时间。
• IDE独立。事实证明，所有主要的IDE，Eclipse，IDEA和NetBeans都对Maven项目提供了不错的支持，因此我们的开发人员不会被锁定在一个特定的IDE中。
• 命令行。使用Maven，支持同时进行的IDE和命令行配置非常简单，这对于持续集成非常有用。

缺点：

• 必须投资学习Maven。好吧，必须这样做。好消息，不是团队中的每个人都必须学习。
• 文档。曾经是个问题，现在感谢Sonatype和他们的书（http://www.sonatype.com/products/maven/documentation/book-defguide），情况要好得多。
• 刚度。以您想要的方式做事有时是充满挑战和挫败感的。我的建议是不要战斗并使Maven做到其最擅长的事情，简单明了的构建或有稳定的mojo可用。在其他情况下，我们退出并使用Ant任务（http://maven.apache.org/plugins/maven-antrun-plugin/）或外部程序进行处理。我个人最喜欢的是Groovy插件（http://groovy.codehaus.org/GMaven）。

竞争：

• Ant：没有依赖关系管理。期。
• 常春藤：仍然不如Maven成熟（不是说后者也没有怪癖）。几乎相同的功能集，因此没有令人信服的理由采取行动。我做了几次尝试。一切都不成功。

底线：我们所有的项目都已经使用Maven完成了几年。

我认为它在拥有最简单和最复杂项目的人员中享有不良声誉。

如果要从单个代码库构建单个WAR，它将迫使您四处移动项目结构，并将三个jar中的两个jar手动列出到POM文件中。

如果要从九个EAR文件原型的集合中构建一个EAR，并结合五个WAR文件，三个EJB和17个其他工具，依赖项jar和配置的组合，则需要在最终构建期间对现有资源中的MANIFEST.MF和XML文件进行调整；那么Maven可能会过于严格。这样的项目变成了复杂的嵌套配置文件，属性文件以及对Maven构建目标和分类器名称的滥用。

因此，如果您处于复杂度曲线的底部10％，则它可能会过高。在那条曲线的顶部10％，您身穿紧身衣。

Maven的增长是因为它对80％的中端市场表现良好

我的经历反映了这里许多帖子的挫败感。Maven的问题在于，在寻求最终的自动魔术优势时，它包装并隐藏了构建管理的细节。如果它破裂，这将使您几乎无助。

我的经验是，通过与嵌套根管类似的经验，通过嵌套的xml文件的网络，maven的任何问题都会迅速退化为数小时的狙击搜寻。

我还曾在非常依赖Maven的商店里工作，而喜欢Maven的人（因为“按一下按钮就可以完成”而喜欢它）的人对此并不理解。Maven构建有100万个自动目标，如果我想花点时间阅读它们的工作，我相信这将很有用。您完全理解的更好的2个目标。

警告：两年前与Maven合作，现在可能会更好。

像Glenn一样，我认为Maven的代表并不糟糕，但代表不一。我已经工作了6个月，专门尝试将一个相当大的项目项目迁移到Maven，这清楚地表明了该工具的局限性。

以我的经验，Maven适用于：

• 外部依赖管理
• 集中管理构建（pom继承）
• 很多用于很多事情的插件
• 与持续集成工具的良好集成
• 非常好的报告功能（FindBugs，PMD，Checkstyle，Javadoc等）

它存在以下问题：

• 全有或全无的方法（很难缓慢迁移到Maven）
• 复合体依赖关系，模块间依赖关系
• 循环依赖（我知道，设计不好，但是我们无法修复5年的开发...）
• 连贯性（版本范围在任何地方都不尽相同）
• 错误（同样是版本范围）
• 可复制的版本（除非您修复所有插件的版本号，否则无法确定在6个月内会获得相同的版本）
• 缺乏文档（该文档对于基础知识来说是相当不错的，但是关于如何处理大型项目的示例并不多）

为了提供一些背景信息，大约有30个开发人员在从事此项目，并且该项目已经开展了5年以上，因此：许多遗留物，许多流程已经到位，许多定制专有工具已经到位。我们决定尝试迁移到Maven，因为维护专有工具的成本太高了。

我想反驳在这个论坛上提出的一些投诉：

Maven要么全有要么全无。或至少据我所知。您不能轻易将maven用作ant的替代品，并逐渐采用更高级的功能。

这不是真的 Maven的一大胜利就是使用它以一种合理的方式管理您的依赖关系，如果您想在maven中做到这一点，并在ant中做其他一切，那么您可以。这是如何做：

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />
  </maven:dependencies>
</project>

现在，您有一个名为'maven.classpath'的类路径对象，其中包含pom文件中定义的所有maven依赖项。您所需要做的只是将Maven ant任务jar放在ant的lib目录中。

Maven使您的构建过程取决于您的网络连接。

默认的依赖项和插件获取过程取决于网络连接，是的，但仅适用于初始构建（或者如果您更改了正在使用的依赖项或插件）。之后，所有jar都在本地缓存。而且，如果您想强制无网络连接，则可以告诉Maven使用脱机模式。

它从一开始就为您强加了刚性结构。

目前尚不清楚这是指文件格式还是“常规与配置”问题。对于后者，有很多不可见的默认值，例如java源文件和资源的预期位置，或源的兼容性。但这不是严格的要求，它会为您设置合理的默认值，因此您不必明确定义它们。所有设置都可以轻松覆盖（尽管对于初学者而言，很难在文档中找到如何更改某些设置）。

如果您正在谈论文件格式，那么在下一部分的回复中将会介绍...

它基于XML，因此像ANT一样难以阅读。

首先，我看不到您怎么能抱怨“不比蚂蚁好”的某方面作为其不良代表的理由。其次，尽管它仍然是XML，但XML的格式要定义得多。此外，由于其定义如此，为POM创建明智的胖客户端编辑器要容易得多。我见过冗长的蚂蚁构建脚本页面，这些脚本遍布各处。任何蚂蚁构建脚本编辑器都不会使它变得更可口，而只是一长串互连任务的列表，它们以略有不同的方式呈现。

话虽如此，但我在这里看到的一些投诉具有或具有某种效力，最大的是

• 文档不佳/丢失
• 可复制的构建
• Eclipse集成不好
• 虫子

我对此有双重回应。首先，Maven是一个比Ant或Make更年轻的工具，因此您必须期望它会花费一些时间来达到那些应用程序的成熟度。其次是，如果您不喜欢它，请修复它。它是一个开源项目，使用它，然后抱怨有人可以解决的事情对我来说似乎很愚蠢。不喜欢文档？为使它变得更清晰，更完整或更便于初学者使用。

可复制的构建问题分为两个问题，版本范围和自动maven插件更新。对于插件更新，除非您确定在一年后重建项目时使用的是完全相同的JDK和完全相同的Ant版本，否则这只是名称不同的问题。对于版本范围，我建议使用可为所有直接和传递依赖项生成具有锁定版本的临时pom的插件，并将其纳入Maven发布生命周期的一部分。这样，您的发行版构建poms始终是所有依赖项的准确描述。

它应有的声誉。并非每个人都需要Maven开发人员认为适合于每个项目的刚性结构。太不灵活了。恕我直言，对许多人来说，“专业版”是依赖性管理，它是最大的“缺点”。我绝对不愿意从网络上下载jar并因不兼容而失去睡眠（是的，存在脱机模式，但是为什么我应该拥有所有数百个xml文件和校验和）。我决定使用哪个库，许多项目对依赖于网络连接的构建有严重的担忧。

更糟糕的是，当事情不起作用时，您绝对会迷路。文档很烂，社区一无所知。

一年后，我想对此进行更新：我不再对Maven社区有这种看法。如果今天提出这个问题，我不会写这个答案。我将添加当前的意见作为单独的答案。

这是一个非常主观的答案，但是问题是关于意见的，所以...

我喜欢Maven，并且对它的了解越多，就越喜欢它。然而，有一件事影响了我对此的感觉：Maven社区主要围绕Sonatype（“ Maven公司”，这是许多Maven honchos工作的地方），并且Sonatype积极地将其公司产品推向社区。

一个示例：“ Maven Book” twitter流链接到假定的存储库管理简介。

抱歉，“介绍”是Nexus的一半信息，一半销售。流行测验：除了Nexus和Nexus Pro，还有其他回购管理器吗？另外，这与所谓的开源Maven Book有什么关系？哦，对了，关于存储库管理的章节已分解为另一本有关Nexus的书。嗯 如果我为Maven图书做出了贡献，如果导致Nexus销售量增加，是否可以获得推荐费？

想象一下，如果您正在参加Java开发论坛，很明显，讨论Java的Sun员工将抓住一切可能的机会来谈论NetBeans和“ NetBeans Pro”。一段时间后，它失去了一些社区感。我从未在Ant那里经历过这样的经历。

综上所述，我确实认为Maven是用于软件开发配置和构建管理的非常有趣且有用的系统（我没有称其为Ant那样的工具，Maven的范围更广）。依赖管理有时是一种祝福，也是一种诅咒，但它令人耳目一新-当然不是Maven提供的唯一优势。我可能对Sonatype先令的反应太强烈了，但是我认为这对Maven造成了伤害。我不知道这个意见是否被其他任何人分享。

我认为Maven受到了不好的说唱，因为它在您的项目上强加了结构，而其他工具（例如Ant）允许您按自己的方式完全定义结构。也同意该文档是不好的，但是我认为Maven收到的不良说唱主要是因为人们已经习惯了Ant。

太神奇了。

因为不满意的人会抱怨而满意的人则不会说他们感到满意。我的观点是，满意的Maven用户比不满意的人要多得多，但后来者会产生更多的噪音。这实际上也是现实生活中的一种常见模式（ISP，电话运营商，运输工具等）。

对我而言，最重要的一个问题是，由于配置不正确，Maven可能无法产生可重复的构建，原因是：

• 远程存储库不可靠；
• 依赖于具有SNAPSHOT版本或没有版本的插件和库。

与此形成对比的是，尽管所有的罐子都是在本地检入的，但尽管IMO冗长且令人厌烦，但它仍能起作用。

好消息是问题可以解决：

• 使用您自己的maven存储库，该存储库已经变得非常简单，我使用Archiva的结果很好；
• 始终正确版本化您的依赖项。Maven已开始锁定超级POM中的插件版本（从2.0.8或2.0.9开始），并且您的所有依赖项都应依赖于已发布的版本。

好主意-执行不力。

我最近将一个项目从Ant移到了Maven。最后效果很好，但是我必须在同一个pom中使用两个不同版本的maven-assembly-plugin和maven-jar-plugin（获得两个配置文件），因为在一个版本中有效的版本在另一个版本中被破坏了。

因此，这非常令人头疼。文档并不总是很好，但我必须承认，使用Google答案相对容易。

确保始终指定要使用的插件版本。不要指望新版本将向后兼容。

我认为争议来自于事实，即Maven仍在发展，有时这个过程很痛苦。

问候

v。

我喜欢行家。从1.0之前的版本开始使用。总之，这是一个功能强大的工具，为我节省了大量时间，并改善了我的开发基础结构。但是我能理解某些人的挫败感。我看到3种挫败感：

1. 原因真正引起关注的地方（例如冗长的POM，缺少文档），
2. 有些是错误的信息（例如“您必须建立互联网连接”-并非如此-可以，这可以避免），
3. 其中一些是通向专家的，但实际上其他人是有罪的（“不要射击信使”）。

对于第一种情况，真正的问题-当然，有问题，POM冗长，文档可能会更好。尽管如此，使用Maven可以在短时间内获得良好的结果。每当我得到一个使用ant构建的项目时，我都会感到畏缩，并尝试将其导入到我的IDE中。设置目录结构可能需要很长时间。使用maven只是在IDE中打开POM文件的一种情况。

对于第二种情况，Maven很复杂，误解很普遍。如果maven 3可以找到解决这种复杂性（甚至感知的复杂性）的方法，那将是很好的。Maven确实需要大量投资，但是以我的经验，这笔投资很快就能收回成本。

最后一点，我认为关于Maven的传递依赖项的抱怨可能是最著名的例子。

传递依赖性是使用重用的实际软件的本质。Windows DLL，Debian软件包，java软件包，OSGi软件包，甚至C ++头文件都具有依赖性，并且会遇到依赖性问题。如果您有两个依赖关系，并且每个依赖关系使用相同版本的不同版本，则必须尝试以某种方式解决该问题。Maven并没有尝试解决依赖关系问题，而是将其带到了最前沿，并提供了帮助解决问题的工具，例如通过报告冲突和为项目层次结构提供一致的依赖关系，实际上提供了对项目的绝对控制。项目的依赖项。

手动在每个项目中包含依赖项的方法（一个张贴者说他将所有依赖项都检查到源代码控制中）冒着使用错误依赖项的风险，例如在更新库时忽略更新，而没有检查其依赖项的更新。对于任何规模的项目，手动管理依赖项肯定会导致错误。使用maven，您可以更新使用的库版本，并包括正确的依赖项。对于变更管理，您可以将旧的依赖性集（对于整个项目而言）与新的依赖性集进行比较，可以仔细检查，测试等任何变更。

Maven并不是引起依赖关系问题的原因，但是使其更加明显。在解决依赖关系问题时，maven使显式的任何依赖关系“调整”（对POM的更改会覆盖该依赖关系）而不是隐式的，就像版本控制中手动管理的jar一样，即简单地存在jar，而无需进行任何操作支持天气，他们是否正确依赖。

我认为Maven的表现不佳，因为大多数批评者都没有观察到Maven + Hudson + Sonar的组合。如果他们有，他们会问“我如何开始”？

我和Maven的一些讨厌的表情：

• XML定义非常笨拙且冗长。他们从未听说过属性吗？

• 在其默认配置下，它总是在每次操作时搜索“ net”。不管这是否对任何事情都有用，但需要Internet访问才能“干净”看起来非常愚蠢。

• 同样，在默认情况下，如果我不小心指定确切的版本号，则无论这些最新版本是否引起依赖项错误，它都会将最新的更新从网络中删除。换句话说，您被别人的依赖管理所左右。

• 所有这些网络访问的解决方案是通过添加-o选项将其关闭。但是，如果您确实要进行依赖项更新，则必须记住将其关闭！

• 另一个解决方案是安装自己的“源代码管理”服务器以获取依赖关系。惊喜：大多数项目已经具有源代码控制，只有在没有其他设置的情况下，它才能起作用！

• Maven构建非常慢。烦恼网络更新可以缓解这种情况，但是Maven构建仍然很慢。而且非常冗长。

• Maven插件（M2Eclipse）与Eclipse的集成最差。Eclipse与版本控制软件和Ant合理地顺利集成。相比之下，Maven集成非常笨拙。我有提到慢吗？

• Maven仍然是越野车。错误消息没有帮助。太多的开发人员正遭受着这种痛苦。

好问题。我刚刚开始工作一个大型项目，以前的项目的一部分是将模块化引入我们的代码库。

我听说过有关Maven的坏消息。实际上，这是我所听说的全部。我看着介绍它来解决我们当前遇到的依赖梦night。我在Maven中看到的问题是它的结构非常僵化，即您需要遵循其项目布局才能使其正常工作。

我知道大多数人会说什么-您不必遵循结构。的确如此，但是直到您超过了最初的学习曲线，您才知道这一点，在那一刻您投入了太多的时间去扔掉所有的东西。

这些天，蚂蚁经常使用，我喜欢它。考虑到这一点，我偶然发现了一个鲜为人知的依赖管理器Apache Ivy。Ivy 很好地集成到Ant中，可以快速轻松地获得基本的JAR检索设置和工作。Ivy的另一个好处是它功能强大但非常透明。您可以很容易地使用诸如scp或ssh之类的机制来传输构建；通过文件系统或远程存储库进行“链式”依赖项检索（Maven存储库兼容性是其受欢迎的功能之一）。

综上所述，我发现最终使用它非常令人沮丧-文档丰富，但是它用不良的英语编写，在调试或尝试找出出问题所在时，可能会增加挫败感。

在该项目的某个时候，我将重新审视Apache Ivy，希望它能够正常工作。它所做的一件事是允许我们作为一个团队来确定我们所依赖的库并获得文档清单。

最终我认为一切都归结为 你作为个人/团队，什么工作，你需要解决你的依赖问题。

您可能会发现与Ivy有关的以下资源很有用：

• Apache Ivy vs Maven 2比较
• Apache Ivy常见问题解答
• Apache Ivy功能列表

我喜欢Maven-它提高了生产率，而且我很高兴不再使用Ant（phe！）。

但是，如果我可以改变事情，那就是：

1. 使pom.xml文件不那么冗长
2. 使从存储库中不包含.jars更容易。

人们不喜欢Maven的原因很多，但面对现实，他们会非常主观。今天的Maven拥有一些不错的（和免费的）书籍，更好的文档，更多的插件集以及很多引用成功的项目构建，与一两年前的Maven不同。

在简单的项目中使用Maven非常容易，对于更大/更复杂的项目，需要更多的知识和对Maven哲学的更深刻的理解-也许在公司级别，像网络管理员这样的Maven专家就职。Maven仇恨陈述的主要来源通常是无知。

Maven的另一个缺点是缺乏灵活性，例如在Ant中。但是，记住Maven的人有一系列约定-坚持这些约定从一开始就很难，但最后通常会避免出现问题。

Maven当前的成功证明了其价值。当然，没有人是完美的，并且Maven有一些缺点和怪癖，但在我看来，Maven缓慢地影响了对手。

我不会说它的代表不好，因为它的代表很复杂。如果您的项目遵循Maven提倡的“配置之上的约定”范式，那么您可以从中获得很多好处。如果您的项目与Maven的世界观不太吻合，那么它可能会成为负担。

为此，如果您对项目有控制权，那么Maven可能是可行的方法。但是，如果您不这样做，并且布局是由不喜欢Maven的人确定的，那可能会比值得的麻烦更多。最幸福的Maven项目可能是从Maven项目开始的项目。

对我来说，在内部项目中使用maven vs ant既有缺点，也有很多优点。但是，对于开源项目，我认为Maven在使许多项目更易于构建方面产生了巨大影响。不久之前，一般的OSS Java（基于蚂蚁）项目需要花费数小时才能编译，必须设置大量变量，下载相关项目等。

您可以使用Maven做任何事情，也可以使用Ant做任何事情，但是在Ant不鼓励任何标准的地方，Maven强烈建议您遵循它的结构，否则将需要更多工作。的确，使用Maven设置某些东西很痛苦，而使用Ant可以轻松完成，但是最终结果几乎总是从那些只想签出项目并继续工作的人的角度来看，更容易构建。

如果您打算将业务或工作押注在开发项目上，则希望控制基础-即构建系统。使用Maven，您将不受控制。它是声明性和不透明的。Maven框架开发人员不知道如何构建透明或直观的系统，而从日志输出和文档中可以清楚地看出这一点。

依赖项管理非常诱人，因为它在项目开始时可能会让您花费一些时间，但是要注意，它从根本上被破坏了，最终将使您头痛。当两个依赖项具有不兼容的瞬态依赖项时，您将被复杂的棘手问题所困扰，这将破坏整个团队的构建并持续数天。众所周知，由于本地存储库状态不一致，因此Maven的构建过程对于团队中的不同开发人员也不一致。根据开发人员创建环境的时间或正在从事的其他项目的不同，他们将获得不同的结果。您会发现您要删除整个本地存储库，并使Maven重新下载jar的次数比首次为dev分支设置的次数要多得多。我相信OSGI是一项尝试解决此基本问题的计划。我想说的是，如果某些事情需要如此复杂，那么基本前提是错误的。

我已经成为Maven用户/受害者超过5年了，我不得不说，这将为您节省更多时间，只需将依赖项检查到源存储库中并编写漂亮而简单的ant任务即可。使用ant，您完全可以知道构建系统在做什么。

由于Maven的问题，我在几家不同的公司经历了很多很多迷路的工作。

我最近试图恢复一个旧的GWT / Maven / Eclipse项目的生命，而在我所有业余时间的2周之后，我仍然无法始终如一地构建它。是时候减少我的损失并使用我认为的ant / eclipse开发了...

简短的答案：我发现维护Maven构建系统非常困难，我想尽快切换到Gradle。

我已经在Maven工作了四年以上。我会称自己为构建系统专家，因为在我进入的最后（至少）五家公司中，我对构建/部署基础结构进行了重大翻新。

我学到的一些经验教训：

• 大多数开发人员往往不会花很多时间在考虑构建系统上。结果，构建变成了意大利面条般的混乱，但是当这些混乱被清理并合理化时，他们的确对此表示赞赏。
• 在处理复杂性时，我宁愿有一个透明的系统来公开复杂性（例如Ant），而不是通过施加严格的限制（例如Maven）来使复杂的事情变得简单的系统。想想Linux与Windows。
• Maven在功能上有很多漏洞，需要拜占庭式的解决方法。这将导致POM文件变得难以理解且无法维护。
• Ant具有超强的灵活性和可理解性，但是Ant文件也可能会变得很大，因为它的级别很低。
• 对于任何重要的项目，开发人员都必须创建超出工具所提供能力的自己的构建/部署结构。结构对项目的适应性与维护的容易程度有关。最好的工具将支持您创建结构而不是与您抗争。

我对Gradle进行了一些研究，看起来它有可能成为两全其美的方法，可以同时使用声明式和过程式构建描述。

它比您用来编写项目的语言还要复杂。正确配置它比实际编程困难。

我一直在努力克服这里提到的大多数/所有负面因素，以及队友的类似异议，并全部同意。但是我坚持不懈，并将坚持坚持只有行家（或者也许是gradle）才能真正实现的一个目标。

如果您正在为同龄人（开源开发人员）进行优化，那么ant / make /无论做什么。如果您要向非对等（用户）交付功能，则只有maven / gradle / etc可以。

只有maven可以让您发布一小束源代码和poms（没有带有加密名称且没有依赖项信息的嵌入式lib / binary依赖罐），其文档化良好的标准项目布局可以由任何IDE加载，而那些没有被吸收的人开发人员的特殊布局约定。有一个一键式安装过程（mvn安装），可在获取所有缺少的依赖项的同时构建所有内容。

结果是这些用户可以轻松找到所需的入门代码，pom可以将其指向相关文档。

除了这个（必不可少的）要求，我和任何人一样都不喜欢Maven。