Question

我一次又一次地阅读和听到人们对Maven感到沮丧以及它有多复杂。并且使用Ant来构建代码要容易得多。

然而，为了：

编译代码
运行测试
打包可部署的单元

这就是Maven所需要的：

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>type something here</groupId>
  <artifactId>type something here</artifactId>
  <version>type something here</version>
</project>

相应的最小Ant构建文件是什么？

Answer 1

As Aaron says，Maven的问题不在于它是如何运作的，而是它失败的原因。

在Ant中，依赖管理是一个你必须手动解决的问题（暂时忽略Ivy，因为它本质上是用螺栓固定到Ant上的Maven方法）。如果您有很多依赖项，这可能会非常耗时，但这只是一次性成本。一旦您将依赖关系组织起来并检入您的版本控制存储库，它就可以正常工作。至少在你必须改变依赖关系之前，希望很少（但有些情况并非如此）。

Maven通过使依赖项动态化来“解决”依赖性问题，因此避免了大部分前期成本，并且更容易更改依赖项。这种灵活性的代价是复杂性。 Maven将你的构建转变为一个分布式系统，并且这样做会导致许多8 Fallacies of Distributed Computing犯规。其中一些问题在理论上比在实践中更多。例如，我不知道任何Maven存储库被泄露的情况，但这并不意味着您不必了解安全隐患。远程存储库的其他问题（例如可靠性，带宽和延迟）是Maven dissatisfaction的更常见原因。

Maven将在本地缓存依赖项，以便在您检索到项目所需的所有内容后，应避免重复访问存储库。但随着时间的推移，随着项目开发人员数量的增加，您需要在几个时间点重新检索依赖项。使用默认的Maven设置，您需要外包依赖项管理。是否可以在需要时立即使用依赖项，或服务器是否已关闭？是否仍可在6个月内从远程存储库中获取？可能，但它不在你的掌控之中。

因此，Maven的支持者会告诉您，您可以并且应该运行自己的Maven存储库，以避免分布式依赖项导致的许多问题。好的，但是在这一点上我们必须停止假装Maven很简单。 Maintaining your own Maven infrastructure can become quite involved

人们过去对Maven生气的另一个原因是它的插件系统。 Maven能够自我更新，但经常这会导致破损。我相信这种行为已经在最近的版本中得到了驯服。

Maven可能仍然是某些环境的最佳解决方案，例如并行开发多个项目并且它们之间存在某种耦合的团队，但它远非痛苦。

Ant也没有疼痛，但疼痛往往是自我造成的，而不是你的控制。您需要引入更高级别的抽象来保持可管理性。 Ant Macros是这方面的有用工具。使用some discipline and sensible conventions（也许就像Maven鼓励的那些？），您可以有效地将Ant用于大型项目。 Ant构建文件就像任何其他程序一样（除了详细的XML语法之外），它需要在事情发生变化时进行维护和重构，而不是直到它看起来有效才被破解。 Ant对它有利的是强大的，它通常会产生可重复的构建，并且有很好的文档记录。

Answer 2

没有相应的最小ant文件。 Maven是使用RoRspeak的固定软件。它假定您的代码所在的位置，编译文件的位置，可分发的位置，如何触发测试以及其他任务的加载。换句话说，基本上没有任何东西需要显式定义为maven才能完成这些任务。

当然，问题是并非一切都符合预定的框架，所以有必要做一些特定的工具，比如蚂蚁（其中所有都是特定的），闪耀：没有区别，你只需要描述你需要的东西。据我了解，这是人们对maven的常见抱怨。另一方面，maven不会阻止配置，因此可以调整它，并在必要时使用ant。

我更喜欢maven用于新项目，因为我可以遵循合理的maven约定，但会在现有项目中使用ant构建脚本。

<强>更新：

更正：对于现有项目，我会长时间，艰难地看一下迁移到maven，然后，如果我真的被推到墙上，请使用ant。我使用maven的次数越多，我就越意识到它的真正价值是多么有价值，以及证明蚂蚁的合理性有多大：立即有价值的插件（即不像蚂蚁那样构建块），标准化（小辈们没有问题跳进去新项目和构建代码），依赖管理，与Hudson / Jenkins的集成......除了极端的项目生命构建之外，很难再证明ant了，至少在我工作的项目类型上。

Answer 3

Maven的问题不在于它何时起作用，而是在它发生故障时。在蚂蚁中，通常很明显如何解决问题。

使用Maven，我需要下载buggy插件的源代码，调试它（这不是微不足道的），修补它，构建新版本的插件，在本地部署（希望有新版本）。这可能导致必须修补其他插件（也要更新它们以使用新版本）。

另外，如果Maven缺少某个功能，我需要编写一个完整的插件或使用antrun插件。

因此，人们必须判断他们可以根据Maven的工作方式调整构建的容易程度以及等待错误修复的时间以及维护复杂的Ant构建脚本的难度。

Answer 4

你已经知道了你的问题（非常有针对性的主体）的答案：没有相当于这个最小POM的Ant，因为与Maven不同，Ant没有定义一套标准，模式，约定，换句话说， 通用语言或项目管理的共享语言，这样就可以让Ant在这个样本上无法击败Maven。

这会让Ant比Maven更复杂吗？不知怎的，是的，我相信大多数关于Maven复杂性的抱怨是由于ignorance（“我知道Ant很好，我知道如何在Ant中做事，Ant很简单，我不知道Maven，我不知道得到它，我不知道怎么做，我感到迷茫，我感到受限制，我不想学习它，Maven很复杂。“）和FUD。但Maven和Ant是如此不同以至于没有真正的点比较它们（而且Maven仍然比Ant +依赖管理更多）。

写这个帮助吗？我不确定。不满意的人会继续咆哮（and make noise）而满意的人会（默默地）继续使用Maven并继续观看 像野火一样传播 。换句话说，没有案例，只是一个吵闹的少数人声称Maven是复杂的（请解释我如何使典型的任务更复杂）和太僵硬（因为Maven没有工作的方式<强>他们想要）。我并不是说Maven适合所有地方，我只是说没有案例。

所以最后（这里没有冒犯）这样的问题不会改变任何东西，我只会引用Maven and Ant guys: you’ll never agree. On anything. Period. Deal with it!.（强烈推荐的帖子）得出结论：

我所说的就是：停止咆哮。要么提出非抽象的解决方案，要么闭嘴。 Ranting很容易。使用您自己的解决方案提出解决方案的情况就不那么好了。

针对Maven的案件？

4 个答案: