为什么是 Maven? 有什么好处？

计算出小型项目的依赖关系并不困难。但是一旦开始处理具有数百个依赖项的依赖树，事情就很容易失控。(这是我的经验之谈...)

另一点是，如果使用具有增量编译和 Maven 支持的 IDE (比如 Eclipse + m2eclipse) ，那么应该能够设置编辑/编译/热部署和测试。

我个人不这样做，因为我已经开始不信任这种模式的发展，由于在过去的糟糕经验(前 Maven)。也许有人可以评论一下 Eclipse + m2eclipse 是否真的有效。

Maven 可以通过使用标准约定和实践来加快开发周期，同时帮助您获得更高的成功率，从而为您的构建过程提供好处。更详细地了解 Maven 如何帮助您完成开发过程，请参阅使用 Maven 的好处。

Maven 是其中一个工具，你需要实际上预先使用 决定，你喜欢它并想使用它，因为你将花费相当多的时间来学习它，一次性做出决定将允许你跳过各种疑问，而学习(因为你 喜欢它和 想要使用它) ！

强大的约定在许多地方有所帮助——比如 Hudson，它可以在 Maven 项目中创造奇迹——但是一开始可能很难看到。

Edit: 从2016年开始，Maven 是唯一一个 Java 构建工具，所有三个主要 IDE 都可以使用开箱即用的源代码。换句话说，使用 maven 使您的构建与 IDE 无关。这允许使用 Netbeans 分析，即使您通常在 Eclipse 中工作

我从没遇到过第二点？您能解释一下为什么您认为这会以任何方式影响部署吗。如果有任何专家允许您以模块化的方式构建您的项目，实际上允许对特定层中的 bug 进行热修复，并允许从项目的其余部分独立开发 API，例如。

有可能您正在尝试将所有内容塞入一个单独的模块，在这种情况下，问题根本不是真正的问题，而是您使用它的方式。

Maven 可以被认为是一个完整的项目开发工具，而不仅仅是构建 Ant 这样的工具。 您应该使用 带有 maven 插件的 Eclipse IDE来解决所有问题。

以下是从 使用 Maven 的好处页面引用的 Maven 的一些优点:

亨宁

• 快速的项目设置，没有复杂的 build.xml 文件，只有一个 POM 文件
• 由于以下原因，项目中的所有开发人员都使用相同的 jar 依赖项 集中式 POM。
• “免费”获得一个项目的大量报告和指标
• 减少源代码分发的大小，因为 jar 可以 从中心位置取出

伊曼纽尔 · 维尼斯

• 很多目标是可以实现的，所以没有必要去发展一些 特定的生产工艺部分相反 我们可以重用现有的 ANT 任务 在构建过程中使用 antrun 插件

杰西 · 麦康奈尔

• 通过简化代码的管理，促进代码的模块化设计 项目，它允许设计是 分成多个逻辑部分, 把这些部分编织在一起 依赖跟踪在 pom 中的使用 文件。
• 加强了代码的模块化设计 代码，但是当代码是分开的时候 编译项目是不可能的 交叉授粉之间的参考 代码模块，除非你 特别允许它在您的 依赖性管理... 没有 我现在就把它修好 后期的实施。
• 用依赖项清楚地声明了依赖项管理 管理机制，你必须尝试 把你的罐子弄坏 版本... 没有任何 经典的问题是 这个供应商的罐子是这个吗?’和设置 在现有的项目上 现有的混乱，如果它 存在的时候，你被迫 存储库中的“未知”版本 让一切运转起来，或者 对自己撒谎说你知道 实际版本的 ABC.jar。
• 强类型生命周期有一个强定义的生命周期 软件系统从 开始建造直到最后。 使用者可以混合使用 将他们的系统与生命周期相匹配 而不是拼凑自己的 生命周期. . 这有额外的 允许人们移动的好处 从一个项目到另一个项目，然后说话 使用相同的词汇 软件开发

文森特 · 马索尔

• 更大的动力: 蚂蚁现在是遗产，并没有快速前进。 Maven 是 快速前进 有很多高价值的潜力 围绕 Maven 的工具(CI，Dashboard 项目、 IDE 集成等)。

计算出包的依赖关系并不是那么困难。反正你也很少这么做。可能在项目安装期间只有一次，在升级期间则很少。使用 maven，您最终将修复不匹配的依赖关系、编写糟糕的 poms，并且无论如何都要执行包排除操作。

对玩具项目来说，没那么难。但是我工作的项目有很多，真的很多，它们，我很高兴得到它们传递，有一个标准化的命名方案。手动管理所有这些将是一场噩梦。

是的，有时你必须处理依赖关系的收敛性。但是仔细想想，这不是 Maven 固有的，而是任何使用依赖关系的系统固有的(我在这里讨论的是一般的 Java 依赖关系)。

因此，对于 Ant，你必须完成 一样的工作，除了你必须手动完成所有事情: 抓取项目 A 的某个版本及其依赖项，抓取项目 B 的某个版本及其依赖项，弄清楚它们使用的确切版本，检查它们是否重叠，检查它们是否不兼容，等等。欢迎来到地狱。

另一方面，Maven 支持依赖关系管理，并将为我检索它们的传递性，并为我提供了管理复杂性 依赖管理固有的特性所需的工具: 我可以分析依赖关系树，控制传递依赖关系中使用的版本，排除其中一些 如果所需的，控制模块间的收敛，等等。根本没有魔法。但至少你还有后援。

不要忘记依赖管理只是 Maven 提供的一小部分，还有更多(甚至不要提到与 Maven 很好地集成的其他工具，例如 声纳)。

缓慢的修复-编译-部署-调试周期，扼杀了生产力。这是我的主要抱怨。如果进行更改，则必须等待 maven 构建生效并等待其部署。没有任何热部署。

首先，你为什么这样使用 Maven？我不知道。我使用 IDE 编写测试、代码，直到测试通过、重构、部署、热部署和运行本地 Maven 构建，以确保不会中断连续的构建。

其次，我不确定使用 Ant 会让事情变得更好。根据我的经验，使用二进制依赖的模块化 Maven 构建比典型的单片 Ant 构建给了我更快的构建时间。无论如何，看一下 玛文 · 谢尔，以便准备(重新)使用 Maven 环境(顺便说一句，这很棒)。

最后，我很遗憾地说，并不是 Maven 扼杀了你的工作效率，而是你滥用了你的工具。如果你不满意，我能说什么呢，别用它。就我个人而言，我从2003年就开始使用 Maven 了，从此再也没有回头。

相对于蚂蚁，专家的优势有很多。我试着在这里总结一下。

约定优于配置
Maven 对于项目布局和启动使用了一种独特的方法，这使得在项目中跳转变得更加容易。通常只需要校验和 maven 命令就可以获得项目的工件。

项目模块化
项目约定建议(或者更好地建议)开发人员将项目模块化。与单一项目不同，您经常被迫将项目划分为更小的子组件，这使得调试和管理整个项目结构更加容易

依赖管理与项目生命周期
总的来说，有了良好的 SCM 配置和内部存储库，依赖性管理就变得非常容易，而且您还必须考虑项目生命周期——组件版本、发布管理等等。比蚂蚁还要复杂一些，但是同样的，项目质量的提高。

Maven 怎么了
玛文并不容易。在 POM 中，构建周期(完成什么以及何时完成)并不那么清楚。此外，组件的质量和公共存储库中缺少的依赖项也会产生一些问题。
(对我来说)最好的方法是建立一个内部存储库，用于缓存(并保持)依赖关系，并应用于组件的发布管理。对于比书中的示例项目更大的项目，您将在之前或之后感谢 Maven