与 ant 相比，使用 Maven 的主要好处是什么？
它似乎更像是一种烦恼，而不是一个有用的工具。
我使用 maven 2、普通 Eclipse Java EE（无 m2eclipse）和 tomcat。
maven的支持者认为
Maven 让您轻松获取包依赖项
Maven 强制你有一个标准的目录结构
在我的经验中
弄清楚包依赖关系实际上并不难。无论如何，你很少这样做。可能在项目设置期间一次，在升级期间几次。使用 Maven，您最终将修复不匹配的依赖项、编写错误的 poms 以及无论如何进行包排除。
缓慢的“修复-编译-部署-调试”周期会降低生产力。这是我的主要抱怨。您进行更改后，您必须等待 Maven 构建启动并等待其部署。没有任何热部署。
或者我只是做错了？请给我指出正确的方向，我洗耳恭听。
弄清楚包依赖关系实际上并不难。无论如何，你很少这样做。可能在项目设置期间一次，在升级期间几次。使用 Maven，您最终将修复不匹配的依赖项、编写错误的 poms 以及无论如何进行包排除。
对于玩具项目来说，没那么难。但我从事的项目有很多，真的很多，我很高兴能够传递它们，为它们制定标准化的命名方案。手动管理所有这些将是一场噩梦。
是的，有时您必须致力于依赖性的收敛。但仔细想想，这不是 Maven 固有的，这是任何使用依赖项的系统所固有的（我在这里谈论的是一般的 Java 依赖项）。
所以对于 Ant，你必须做same工作，除了你必须手动完成所有事情：获取项目 A 的某个版本及其依赖项，获取项目 B 的某个版本及其依赖项，自己弄清楚它们使用的确切版本，检查它们是否不重叠，检查它们是否存在不兼容等等。欢迎来到地狱。
另一方面，Maven 支持依赖管理，并将为我传递地检索它们，并为我提供管理复杂性所需的工具依赖管理固有的：我可以分析依赖树，控制传递依赖中使用的版本，排除其中一些if需要，控制跨模块的收敛等。没有什么神奇的。但至少你有支持。
并且不要忘记依赖管理只是 Maven 提供的一小部分，还有更多（更不用说与 Maven 很好地集成的其他工具，例如Sonar).
缓慢的“修复-编译-部署-调试”周期会降低生产力。这是我的主要抱怨。您进行更改后，您必须等待 Maven 构建启动并等待其部署。没有任何热部署。
首先，为什么要这样使用Maven？我不。我使用 IDE 编写测试、代码，直到通过、重构、部署、热部署，并在完成后、提交之前运行本地 Maven 构建，以确保不会破坏持续构建。
其次，我不确定使用 Ant 会让事情变得更好。根据我的经验，使用二进制依赖项的模块化 Maven 构建比典型的整体 Ant 构建提供了更快的构建时间。无论如何，看看Maven 外壳准备好（重新）使用 Maven 环境（顺便说一下，这很棒）。
所以最后，我很遗憾地说，并不是 Maven 真正扼杀了你的生产力，而是你滥用了你的工具。如果你对它不满意，那么，我能说什么，不要使用它。就我个人而言，我从 2003 年就开始使用 Maven，并且从未回头。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
