为什么是 maven？有什么好处？[已关闭]

弄清楚包依赖关系真的不是那么难。反正你很少这样做。可能在项目设置期间一次，在升级期间很少。使用maven，你最终会修复不匹配的依赖项，写得不好的pom，并无论如何执行包排除。

没那么难...用于玩具项目。但是我从事的项目有很多，真的很多，我很高兴能传递它们，为它们提供标准化的命名方案。手动管理所有这些将是一场噩梦。

是的，有时你必须研究依赖关系的收敛。但是三思而后行，这不是Maven固有的，这是任何使用依赖关系的系统所固有的（我在这里谈论的是Java依赖关系）。

因此，使用Ant，您必须执行相同的工作，除了您必须手动执行所有操作之外：获取项目A的某些版本及其依赖项，获取项目B的某些版本及其依赖项，弄清楚它们使用的确切版本，检查它们是否不重叠，检查它们是否不兼容，等等。欢迎来到地狱。

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

不要忘记，依赖管理只是Maven提供的一小部分，还有更多（甚至没有提到与Maven完美集成的其他工具，例如Sonar）。

缓慢的 FIX-COMPILE-DEPLOY-DEBUG 周期，这会扼杀生产力。这是我的主要抱怨。你做了一个改变，你必须等待maven构建启动，等待它部署。没有任何热部署。

首先，你为什么这样使用Maven？我没有。我使用我的IDE来编写测试，编写代码直到它们通过，重构，部署，热部署并在完成后运行本地Maven构建，然后再提交，以确保我不会破坏连续构建。

其次，我不确定使用Ant会让事情变得更好。根据我的经验，使用二进制依赖项的模块化Maven构建使我比典型的整体式Ant构建更快地构建时间。无论如何，看看Maven Shell是否有一个准备（重新）使用的Maven环境（顺便说一句，这真是太棒了）。

所以最后，我很抱歉地说，并不是真正的Maven在扼杀你的生产力，而是你滥用了你的工具。如果你对它不满意，好吧，我能说什么，不要使用它。就个人而言，我从2003年开始使用Maven，我从未回头。

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

以下是Maven的几个优点，引自使用Maven页面的好处：

亨宁

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

伊曼纽尔·韦尼塞

• 有很多目标可用，所以没有必要开发一些与ANT相反的特定构建过程部分，我们可以在使用antrun插件的构建过程中重用现有的ANT任务。

杰西·麦康奈尔

• 促进代码的模块化设计。通过简化管理多个项目，它允许将设计布局为多个逻辑部分，通过在pom文件中使用依赖关系跟踪将这些部分编织在一起。
• 强制执行代码的模块化设计。对模块化代码进行口头服务很容易，但是当代码在单独的编译项目中时，除非您在依赖关系管理中特别允许，否则不可能在代码模块之间交叉授粉引用...没有“我现在就这样做，以后再修复它”的实现。
• 明确声明依赖关系管理。使用依赖关系管理机制，您必须尝试搞砸jar版本控制...没有“这个供应商罐子的哪个版本？在现有项目上设置它，如果它存在，当你被迫在存储库中创建“未知”版本以使事情启动并运行时，它会撕掉现有混乱的顶部......或者对自己撒谎，你知道ABC.jar的实际版本。
• 强类型化的生命周期 有一个强大的定义生命周期，软件系统从构建的启动到结束...并且允许用户将他们的系统与生命周期混合和匹配，而不是拼凑自己的生命周期。这还有一个额外的好处，即允许人们从一个项目移动到另一个项目，并在软件构建方面使用相同的词汇进行发言。

文森特·马索尔

• 更大的动力：蚂蚁现在是遗产，没有快速前进。Maven正在快速前进，并且有可能围绕Maven拥有许多高价值工具（CI，Dashboard项目，IDE集成等）。