为什么selectmaven？ 有什么好处？
比起ant来说，使用maven的主要好处是什么？ 这似乎比一个有用的工具更烦人。 我使用maven 2，使用纯Java Eclipse EE（无m2eclipse）和tomcat。
maven的支持者相信
-
Maven可以让你轻松获得你的包依赖
-
Maven强迫你有一个标准的目录结构
在我的经验中
-
弄清楚软件包依赖关系并不是那么难。 你反正很less这样做。 在项目设置过程中可能只有一次，在升级过程中可能只有几次。 有了maven，你最终可以修复不匹配的依赖关系，写不好的poms，并且不pipe怎样都会打包排除。
-
缓慢的FIX-COMPILE-DEPLOY-DEBUG循环，杀死生产力。 这是我的主要抱怨。 你做了一个改变，你必须等待Maven构build才能启动并等待它部署。 没有任何热门的部署。
还是我只是做错了？ 请指点我正确的方向，我是耳朵。
弄清楚软件包依赖关系并不是那么难。 你反正很less这样做。 在项目设置过程中可能只有一次，在升级过程中可能只有几次。 有了maven，你最终可以修复不匹配的依赖关系，写不好的poms，并且不pipe怎样都会打包排除。
没有那么难…玩具项目。 但是我所从事的项目有很多，其中很多是我们的，我很高兴能够对它们进行传递，为它们制定一个标准化的命名scheme。 手动pipe理所有这些将是一场噩梦。
是的，有时你必须研究依赖关系的融合。 但是想一想，这不是Maven固有的，这是任何使用依赖关系的系统所固有的（我在这里一般都是讨论Java依赖关系）。
所以对于Ant来说，除了必须手工完成所有工作之外，还必须完成相同的工作：抓取某个版本的项目A及其依赖项，获取某个版本的项目B及其依赖项，找出自己使用的确切版本，检查他们不重叠，检查他们不兼容，等等。欢迎来到地狱。
另一方面，Maven支持依赖pipe理，并且会为我传递检索它们，并提供我需要的工具来pipe理依赖pipe理固有的复杂性：我可以分析一个依赖树，控制传递依赖中使用的版本，排除一些他们如果需要的话，控制跨模块会聚，等等。没有魔法。 但至less你有支持。
不要忘记，依赖pipe理只是Maven提供的一小部分，还有更多（甚至没有提到与Maven完美集成的其他工具，例如Sonar ）。
缓慢的FIX-COMPILE-DEPLOY-DEBUG循环，杀死生产力。 这是我的主要抱怨。 你做了一个改变，你必须等待Maven构build才能启动并等待它部署。 没有任何热门的部署。
首先，你为什么要这样使用Maven？ 我不。 我使用我的IDE编写testing代码，直到他们通过，重构，部署，热部署，并在完成之前运行本地Maven构build，然后提交，以确保不会中断连续构build。
其次，我不确定使用Ant会让事情变得更好。 就我的经验而言，使用二进制依赖关系的模块化Maven构build比通常的单一Ant构build更快的构build时间。 无论如何，看一下Maven Shell ，准备好（重新）使用Maven环境（这非常棒）。
所以最后，我很遗憾地这么说，Maven并不是真正的杀死你的生产力，而是你滥用了你的工具。 如果你不满意，那么我可以说什么，不要使用它。 就我个人而言，我从2003年开始使用Maven，并且从不回头。
Maven可以被认为是完整的项目开发工具，而不仅仅是像Ant一样构build工具。 您应该使用Eclipse IDE与Maven插件来解决所有的问题。
这里有几个Maven的好处 ，引用了使用Maven页面的好处 ：
亨宁
- 快速的项目设置，没有复杂的build.xml文件，只是一个POM和去
- 由于集中式POM，项目中的所有开发人员都使用相同的jar依赖项。
- 为项目“免费”获取大量报告和指标
- 减less源分布的大小，因为瓶子可以从中心位置拉出
Emmanuel Venisse
- 有许多目标可用，所以没有必要开发一些与ANT相反的特定构build过程部分，我们可以在antrun插件的构build过程中重用现有的ANT任务
杰西·麦克康纳
- 促进代码的模块化devise。 通过简化pipe理多个项目，可以将devise分解为多个逻辑部分，通过使用pom文件中的依赖关系跟踪将这些部分编织在一起。
- 强化代码的模块化devise。 它很容易支付模块化的代码，但是当代码是在单独的编译项目中，不可能在代码模块之间交叉授粉引用，除非你明确地允许它在你的依赖pipe理中……没有现在就做这个并且修改它以后的实现。
- 依赖pipe理是明确宣布的。 有了依赖pipe理机制，你必须尝试搞砸你的jar版本……没有一个经典的问题“哪个版本的供应商jar是这个？ 在现有的项目中设置它，如果它存在，当你不得不在你的仓库中创build“未知”版本来启动和运行时，它会把现有的混乱重新排列起来，或者说谎言，你知道ABC.jar的实际版本。
- 强types化的生命周期有一个明确的生命周期，即一个软件系统从一个构build的开始直到结束……用户被允许混合和匹配他们的系统到生命周期而不是在自己的生命周期中拼凑起来。这还有一个额外的好处，就是允许人们从一个项目转移到另一个项目，并且在软件构build方面使用相同的词汇
文森特·马索尔
- 更大的动力：ant现在是遗产，并没有快速前进。 Maven正在快速发展，Maven（CI，Dashboard项目，IDE集成等）有很多高价值工具的潜力。
搞清楚小项目的依赖关系并不难。 但是一旦你开始处理一个有数百个依赖关系的依赖关系树，事情就很容易失控。 （我在这里讲经验…）
另一点是，如果你使用增量编译和Maven支持（比如Eclipse + m2eclipse）的IDE，那么你应该可以设置编辑/编译/热部署和testing。
我个人不这样做，是因为过去不好的经历（Maven之前），我不相信这种发展模式。 也许有人可以评论这是否与Eclipse + m2eclipse实际工作。
Maven是你需要真正决定前台的工具之一，因为你会花费相当多的时间来学习它，并且一劳永逸地做出这个决定将允许你跳过所有的types学习时有疑问（因为你喜欢它， 想用它）！
强大的惯例在很多地方都有所帮助 – 像Hudson一样可以在Maven项目中创造奇迹 – 但最初可能很难看到。
编辑：截至2016年Maven是唯一的Java构build工具，所有三个主要的IDE都可以使用开箱即用的源代码。 换句话说，使用maven可以使你的IDE不可知。 这允许例如使用Netbeans分析，即使你在eclipse中正常工作
Maven比ant更有优势。 我试着在这里总结一下。
约定优于configuration
Maven在项目布局和启动方面使用了独特的方法，这使得在项目中简单地跳转。 通常只需要使用checkount和maven命令来获取项目的工件。
项目模块化
项目公约build议（或者更好地强迫）开发者将项目模块化。 通常你不得不把项目分成更小的子组件，这样就更容易debugging和pipe理整个项目结构
依赖pipe理和项目生命周期
总的来说，通过一个好的SCMconfiguration和一个内部存储库，依赖pipe理是非常容易的，而且你又被迫从项目生命周期 – 组件版本，版本pipe理等等方面考虑。 比ant稍微复杂一点，但同样是项目质量的提高。
maven有什么问题？
Maven并不容易。 构build周期（什么时候完成）在POM中不太清楚。 此外，公共存储库中组件的质量和缺less依赖关系也会出现一些问题。
（对我来说）最好的方法是有一个内部的仓库来caching（和保持）依赖关系，并应用于组件的发布pipe理。 对于比书中示例项目更大的项目，您会在之前或之后感谢maven
Maven可以通过采用标准的惯例和实践来加速您的开发周期，同时帮助您实现更高的成功率，从而为您的构build过程带来益处。 有关Maven如何帮助您开发过程的更详细信息，请参阅使用Maven的好处。
我从来没有遇到第二点？ 你能解释一下为什么你认为这会影响部署吗？ 如果有任何maven允许你以模块化的方式构build你的项目，实际上可以修复特定层中的错误，并允许从项目的其余部分独立开发API。
你可能试图将所有东西都塞进一个单独的模块中，在这种情况下，这个问题根本就不是真正的麻烦，而是你使用它的方式。
Maven是一个强大的基于POM（项目对象模型）的项目pipe理工具。 它用于项目构build，依赖和文档。 它简化了像ANT这样的构build过程。 但它比ANT先进得多。 Maven有助于pipe理构build，文档，Reporing，SCMs，发布，分发。 – maven仓库是一个包含pom.xml文件的打包JAR文件的目录。 Maven在存储库中search依赖关系。
这应该是一个评论，但它不符合评论长度，所以我张贴它作为答案。
在其他答案中提到的所有好处都可以通过比使用maven更简单的方法来实现。 例如，如果你是一个项目的新手，那么无论如何，你将花更多的时间来创build项目架构，join组件，编码，而不是下载jar并将其复制到lib文件夹。 如果你在你的领域有经验，那么你已经知道如何用什么库开始项目。 我没有看到使用maven的好处，特别是在自动执行“依赖pipe理”的时候会带来很多问题。
我只有中级知识的maven，但我告诉你，我做了大型项目（如ERP），而不使用maven。
