为什么行家？有什么好处？[关闭]

与使用ant相比，使用maven的主要好处是什么？它似乎比有用的工具更令人讨厌。我将maven 2与普通的Eclipse Java EE（无m2eclipse）和tomcat一起使用。

Maven的支持者认为

1. Maven让您轻松获取软件包依赖关系

2. Maven强制您使用标准目录结构

在我的经验中

1. 弄清软件包的依赖关系并不难。无论如何，您很少这样做。在项目设置过程中大概一次，在升级过程中可能再一次。使用maven，您最终将解决不匹配的依赖项，错误编写的pom，以及无论如何都要进行包排除。

2. FIX-COMPILE-DEPLOY-DEBUG周期缓慢，这会降低生产率。这是我的主要抱怨。进行更改后，您必须等待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的好处：

亨宁

• 快速的项目设置，没有复杂的build.xml文件，只需一个POM即可
• 由于集中式POM，项目中的所有开发人员都使用相同的jar依赖项。
• 免费获得项目的大量报告和指标
• 减少源分布的大小，因为可以从中央位置拉罐子

伊曼纽尔·韦尼塞（Emmanuel Venisse）

• 有许多目标可用，因此不必开发与ANT相反的特定构建过程部件，我们可以使用antrun插件在构建过程中重用现有的ANT任务

杰西·麦康奈尔

• 促进代码的模块化设计。通过简化多个项目的管理，可以将设计布局为多个逻辑部分，并通过在pom文件中使用依赖跟踪将这些部分编织在一起。
• 加强代码的模块化设计。对模块化代码进行口述服务很容易，但是当代码在单独的编译项目中时，除非在依赖管理中明确允许，否则不可能在代码模块之间交叉授粉引用…请立即执行此操作，并在以后的实现中对其进行修复。
• 明确声明了依赖管理。使用依赖项管理机制，您必须尝试搞砸jar版本...没有一个经典的问题，“这是该供应商jar的哪个版本？” 如果您被迫在存储库中创建“未知”版本以启动并运行它，那么在现有项目上进行设置可消除现有混乱（如果存在）的麻烦……或者对自己说谎，您知道ABC.jar的实际版本。
• 强大的类型化生命周期从软件的构建到构建结束，整个生命周期都有很强的定义性……并且允许用户将系统与生命周期进行混合和匹配，而不必将自己的生命周期拼凑在一起。这还有一个额外的好处，即允许人们从一个项目转移到另一个项目，并在软件构建方面使用相同的词汇来讲话

文森特·马索尔

• 更大的发展势头：蚂蚁现在已成为传统，并没有快速前进。Maven正在快速发展，并且有可能在Maven周围拥有许多高价值工具（CI，Dashboard项目，IDE集成等）。

弄清小型项目的依赖性并不难。但是，一旦开始处理具有数百个依赖关系的依赖关系树，事情就很容易失控。（我是根据经验讲的...）

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

我个人不这样做，因为由于过去的不良经验（Maven之前），我开始不信任这种开发方式。也许有人可以评论这是否真的适用于Eclipse + m2eclipse。

Maven是您实际上需要预先决定并想要使用它的工具之一，因为您将花费大量时间学习它，并且一劳永逸地做出了上述决定将使您可以跳过所有种类在学习过程中毫无疑问（因为您喜欢它并想使用它）！

强大的约定在许多地方都可以提供帮助，例如可以在Maven项目中创造奇迹的哈德森，但起初可能很难看到。

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

与蚂蚁相比，Maven的优势很多。我在这里总结一下。

配置上的约定
Maven使用独特的方法进行项目布局和启动，这使跳转项目变得容易。通常，只需要使用checkount和maven命令即可获得项目的工件。

项目模块化
项目约定建议（或更好地迫使）开发人员对项目进行模块化。您常常不得不将项目划分为较小的子组件，而不是整体项目，这使调试和管理整个项目结构更加容易

依赖性管理和项目生命周期
总体而言，凭借良好的SCM配置和内部存储库，依赖性管理非常容易，并且您再次被迫考虑项目生命周期-组件版本，发布管理等。比蚂蚁稍微复杂一点，但是又提高了项目质量。

Maven有什么问题？
Maven并不容易。在POM中，构建周期（完成的时间和时间）不是很清楚。此外，组件的质量和公共存储库中缺少依赖项也会引起一些问题。
最好的方法（对我而言）是拥有一个内部存储库，用于在周围缓存（并保留）依赖项，并将其应用于组件的发布管理。对于大于一本书中的示例项目的项目，您将在之前或之后感谢maven

Maven可以通过采用标准约定和惯例来加快构建周期，同时为您提供更高的成功率，从而为您的构建过程带来好处。有关Maven如何帮助您进行开发的详细信息，请参阅《使用Maven的好处》。

Maven是基于POM（项目对象模型）的功能强大的项目管理工具。它用于项目构建，依赖关系和文档。它像ANT一样简化了构建过程。但是它比ANT先进得多。Maven帮助管理-构建，文档，恢复，SCM，发布，分发。-maven存储库是打包的JAR文件和pom.xml文件的目录。Maven在存储库中搜索依赖项。

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

您可能试图将所有内容都塞进一个模块中，在这种情况下，问题根本不是真正的专家，而是您使用它的方式。

这本来应该是评论，但不适合评论长度，因此我将其发布为答案。

其他答案中提到的所有好处都可以通过比使用maven更简单的方法来实现。例如，如果您是一个项目的新手，则与下载jar并将其复制到lib文件夹相比，您将花费更多的时间来创建项目体系结构，连接组件，编码。如果您有相关领域的经验，那么您已经知道如何使用哪些库来启动该项目。我看不到使用Maven的任何好处，尤其是当它在自动执行“依赖管理”时带来很多问题时。

我只有Maven的中级知识，但是我告诉你，我已经在不使用Maven的情况下完成了大型项目（如ERP）。