我认为这个问题是Compare to the IDE for Java,do we still need Ant?的扩展为什么我们需要Maven或Ant，如果我们已经有Eclipse？
上面的问题有答案，但我想知道在Eclipse上使用Maven或Ant的具体示例。
当我在Eclipse中开发时，Eclipse为我做了一切，我只需要点击运行按钮。而且，Eclipse可以让您将代码导出到可运行的jar或甚至windows的.exe文件。
所以我真的不知道为什么我需要Maven或Ant。
而且，如果我确实需要，哪一个我应该选择，Maven还是Ant？
Eclipse是一个开发环境。但它不是一个构建工具。
我个人讨厌Maven，但是YMMV。有很多选择：gradle，buildr等。
Maven和Ant用于构建脚本，以便它们可以像Jenkins或命令行一样在批处理作业中执行。实际上，Eclipse本身使用Ant广泛地构建插件。
如果您要学习其中的一种，请学习Maven，这是几乎每个人现在使用的一种（取代Ant）。
gradle很流行，它现在在android studio – barlop
使用Ant或Maven有许多优点。
Maven或多或少是Ant的更新概念。 我决定采取另一种方法来回答这个问题，而不是给你一个重点答案。我会问你一个简单的问题。我假设你会成为一名开发人员;或者有某种OO编程背景。
因此，如果您的经理要求您复制两百个目录，但忽略这些目录中的jar, war and ear文件并一旦复制。然后将这两百个目录部署到另一个目标，但只部署.class文件;将其余的文件复制到另一个目的地等。
对于你在java中这样做;它会有很多逻辑，很多代码，并且不会被扩展或适应变化。因此，考虑到Ant或Maven将会为您的应用程序使用更少的开销而完成并准备好所有这些内容。与Java相比，ant或Maven中代码的大小将为1/4。
点击链接，了解更多的技术优势：
Ant我找不到同惠正宗的答案，但我敢肯定，这将说服你;）
Maven的罢工作为一些过去他们销售的c-shell脚本小子写的东西，他们认为autoconf是前沿代码自动化，并且不了解目标代码要求要求对象环境处于任何方式都有效f或开发或部署。蚂蚁已经够糟糕了，但Maven结合了Ant和Ivy的所有最糟糕的功能。它不会创建一个对象环境，并且它不适合使用它的工具。
简而言之，对象环境应该包含所有类对象，即确定系统可用对象类型的对象，它们始终处于活动状态并且可用。从那里我可以做任何我想做的事情，实例化一个类的多个对象，设置各种序列和实例化规则等等。由于环境应该是完全活的，我不应该需要构建工具。在部署我的应用程序方面，环境并不难简单地将构成我的应用程序的命名空间中的所有类代码从未被代码引用过。 JVM中的垃圾收集器在今天执行几乎相同的事情。此时，我有一个由我的对象和我的对象引用的所有对象（主要是类对象）组成的部署环境，即我的应用程序和所有依赖项。这就是虚拟机的工作原理。 （我们的虚拟机写得很差，我们需要在另一台Linux虚拟机上的VMWare VM上的Linux VM上的Java VM上运行Spring VM，这是软件开发白痴的另一个例子）。当依赖关系得到更新时，环境提示开发人员将旧代码合并到新库中，将新代码合并到旧版本或保留两个版本，这足够简单。提示鼓励开发人员进行微小的修改，有时需要避免每个库有二十个版本，而像Maven这样的工具隐藏了您拥有二十个版本的事实，并导致Java应用程序中常见的大量运行时膨胀。
在Java开发领域，Eclipse最接近成为适当的对象环境，尽管有许多插件以各种方式打破范例。当批判性地检查时，使用Maven的大多数原因都会崩溃。 Netbeans和Idea是夸大的文本编辑器，而不是对象环境，但是如果您确实希望将他们的工具用于未被成千上万个Eclipse插件覆盖的内容，那么这两个工具都可以导入和维护Eclipse项目，您的构建只会非常不合理与使用Eclipse的开发人员相比较慢，但是，如果他们纯粹是Netbeans或Idea项目，他们会很慢。
不是使用Maven的严重原因。
在Eclipse中轻松导出/导入设置（任何情况下，每个团队都应该在任何IDE中执行的操作）使得不同的设置问题无非就是开发团队的懒惰（或关于空间vs vs标签，哈哈）。
同样，使用Maven的原因不是很严重。
团队环境？向我展示一个尚未使用GIT或SVN等存储库的团队。为什么我们需要通过设置Nexus回购来复制功能和维护头痛？
那其实是一个很好的理由不是要使用Maven。
运行服务器构建？现在，好主意不应该被代码实际上检入中的源代码回购，而不是恰巧被推送到Nexus的随机构建？这提出了一个反对Git的观点，特别是Git和Maven。因为在Git中，我不在分支上工作，在本地测试，然后提交（部分原因是由于Jenkins和Eclipse中Maven配置的差异，我的本地测试无法证明服务器构建工作），所以我必须将更改提交给一个不同的分支为了看到服务器Maven构建失败，然后提交进一步的修改来解决问题，导致repo中的源代码不可读。检查代码应该至少构建并通过单元测试，如果Git和Maven超出了图片范围，应该保证。
从Eclipse导出无头构建是微不足道的 - 如果您真的关注它 - 只需要ant或Gradle，开发人员构建已由Eclipse维护，并且有几个Eclipse jar（Eclipse将导出所有必需的文件以供无头构建到目录或zip文件，或者ftp到构建服务器）。像Hudson/Jenkins这样的服务器构建工具可以从大多数源代码仓库中提取更新的代码并调用任何构建脚本，因此不依赖于Maven。使用Maven，你可以强迫开发人员使用不适合任何人的工具，而是建立工程师（构建工程所需的时间更长，即使使用M2E也足以满足这种需求），或者您也可以承担服务器构建的可能性不起作用相当于像工作站构建，这是仍然如果你经历了所有使用过多的M2E插件整合两者的麻烦真的。无论哪种方式，你会得到一个更慢，更脆弱的工作站构建，以便同样缓慢和更脆弱的服务器构建。在所有基于Maven的项目中，我已经看到了暂时的Hudson/Jenkins错误，除非您已经绝对安装了可能的M2E插件并且正确配置，否则绝大多数开发人员都不会这样做。
似乎是避免Maven的另一个重要原因。
这并不包括Maven的一些更基本的问题，比如它的命名空间打破了Java命名空间和XML命名空间，它的构建单元（POM）与实际部署环境中的任何东西都没有任何关系（想想它，当你通过POM分离时，你在成品中实际完成了什么？没有什么，它所完成的只是一种错觉，你已经将关注点和功能分成不同的构建单元，所有运行作为一个整体代码块）。手动维护复杂配置文件的麻烦，如果您碰巧需要使用OSGi或其他容器，并且必须维护其他配置文件，这些配置文件会影响Maven配置并受其影响，但这种配置文件很难理解;试图运行单元测试而没有完整的代码执行环境所导致的问题;无数的版本不仅依赖关系，但具体的Maven插件（其实我已经见过地狱JAR在Maven构建本身在多个Maven插件是使用依赖性冲突 - 的Maven的是应该一个问题解决
是的，你可以用Maven构建目标代码。你可以也写在C或纯粹的目标代码，甚至汇编，但我不知道你为什么想要。
避免的Maven的最佳理由是工作的，当你生病的上面提到的所有问题（和许多其他未提及的）脱mavenize一组项目所需的数量惊人。
从C开发中继承的开发周期包括编写代码，编译，汇编，构建，部署，测试，再次完成的思维模式在对象环境中是绝望的过时的。在某个时刻，我们需要用这种心态告诉所有的人，他们需要重新学习如何发展，期间。这样做可以消除对Maven，Git和其他大量工具的需求，这些工具只会浪费时间。
对象的发展应该在活动对象的环境中，因为它被保存，因为修改的对象是活的代码变化进行测试来完成。部署应包括从该环境中仅删除开发人工因素，创建一个运行时，其中包含开发和测试中运行的应用程序的所有内容。
我目前正在处理由使用Maven的组装插件一个OSGi应用程序创建部署组件的一个问题。该应用程序在Eclipse环境中完美工作，该环境将所有代码更改部署到环境中正在运行的OSGi容器中。然而，尽管拥有一个非常好的配置/构建工程师，但他们的唯一工作就是完成这个过程，但在Maven组装过程中，配置不会完好无损。如果我们摆脱了Maven（由于代码量很大，但是可能很困难），并且使用了BNDTOOLS Eclipse插件，我们可以简单地将Eclipse构建版导出为Ant或Gradle无头版本（请注意，编写BND的OSGi开发人员和BNDTOOLS 不支持Maven，并且出于很好的理由，Maven插件是由Felix开发人员编写的，他们自己使用Netbeans和Maven，除了部署周期结束时没有任何活动环境），其中两个工具都已设置与Eclipse相同的环境，不包含仅供开发人员使用的GUI对象。结果将是一个相同的配置和部署构建。这样每个开发人员每天可以节省2-3小时，每个开发人员目前都在观看缓慢的Maven或M2E构建，然后释放配置/构建工程师在部署主机上执行更多的应用程序测试。
克服编写/编译/汇编/构建/部署/测试的思想是唯一的主要障碍。假设你在1979年的VT100终端上编码，而不是现代化的机器，这不会让你成为一个真正的开发者，它只是表明你的方法已经过时了35年。
在团队中的开发人员中，其他人都没有正确理解像Eclipse这样的实时对象环境，以充分利用它作为M2E和OSGi的实时环境工作，他们是顶级开发人员，他们只是没有由于过时的命令行开发工具的普遍使用而暴露于此。他们只知道，原来是可能这样做的时候，我们是结对编程解决配置问题和我分享我的画面，引起了其他团队成员之一惊呼“这你如何写代码，使该死的快”，当他看到我的代码更改立即在后台OSGi容器中测试自己。我可以在必要时使用bash shell，比如当我在远程服务器上查看日志时，实际上我可以非常高效地完成这项工作，以便尽快摆脱该环境，并返回到第21步世纪。
作为一家前公司的实验，在构建完成后，我们让一个团队继续Maven构建，而另一个团队使用Eclipse构建。 Maven构建每月保存建筑工程师约30分钟。然而，每个开发人员每天花费近3小时的时间，Maven的成本与Eclipse构建成本相当。 –
我们已经尝试过这些工具，他们都比较麻烦，然后他们值得。我唯一的遗憾是，我只有一个投票给你。 – Vincent
“与使用Eclipse的开发人员相比，您的构建将会非常慢”证明或编辑 –
Maven通常用于构建特定应用程序的插件或罐子。
假设您开发了一个应用程序，但您不想去手动添加该应用程序所需的罐子。在这种情况下，Maven或Ant很有帮助。一旦你编写了你的代码，只需运行 - > Maven Build（点击Maven Build），它将生成所有必需的插件或jar，并包含在你的应用程序库构建路径中。有人会怀疑应用程序如何获得这些jar包，对于每个应用程序，都有一个名为POM.xml的xml文件，其中所有jar的引用都保存在那里以用于下载目的。
你在一个团队工作吗？ –
贵公司决定他们希望每天凌晨2点进行自动生成。你想在那个时候开始工作来点击IDE中的导出过程吗？即使在周末？ –
我看到很多人使用Eclipse和Ant，而没有问杰克逊问过这个非常重要的问题。去杰克逊的路！问题在于，大多数人/公司都在努力争夺竞争对手，他们没有时间学习可以帮助他们节省更多时间的工具和技术。 – Nav