我认为这个问题是Compare对Java IDE的扩展，我们还需要Ant吗？
上面的问题有答案，但我想知道一个在Eclipse上使用Maven或Ant的具体例子。
当我在Eclipse中开发时，Eclipse会为我做所有的事情，我只需要单击运行按钮。此外，Eclipse还可以让您将代码导出到可运行的jar，甚至是windows的.exe。
所以我真的不知道为什么我需要Maven或Ant。
如果我确实需要，我应该选择哪一个，Maven还是Ant
- 因为你的同事可能更喜欢NetBeans或IDEA
- 因为不同的eclipse安装的设置可能会有所不同
- 因为您可能希望自动获取依赖项
- 因为您想要自动化整个构建：构建、jar、应用静态代码分析、运行单元测试、生成文档、复制到某个目录、根据环境调整某些属性等
- 因为一旦实现自动化，您就可以使用一个连续集成系统，该系统在每次更改或每小时构建应用程序，以确保一切都能构建，测试仍然通过
- 因为Maven使用约定而不是配置
- 因为您的IDE可能不支持您所需要的某些奇特的代码生成/转换
- 因为构建脚本记录了构建过程
Eclipse是一个开发环境。但它不是一个构建工具。
我个人讨厌Maven，但是YMMV。有许多替代方案：gradle、buildr等。
Maven让我印象深刻，它是一群过去销售的c-shell脚本孩子写的东西，他们认为autoconf是领先的代码自动化，不理解对象代码需要对象环境以任何方式高效地进行开发或部署。Ant已经够糟糕的了，但Maven结合了Ant和Ivy所有最糟糕的功能。它不能创建一个对象环境，而且它不能很好地使用这样做的工具
简单地说，对象环境应该具有所有类对象，即确定系统可用对象类型的对象，这些对象在任何时候都是活动的和可用的。从那里我可以做任何我想做的事情，实例化一个类的多个对象，设置各种序列和实例化规则，等等。由于环境应该是完全活动的，我根本不需要构建工具。在部署我的应用程序方面，环境简单地抛出组成我的应用的命名空间中从未被代码引用的所有类对象并不困难。JVM中的垃圾收集器今天在运行中几乎做同样的事情。在这一点上，我有一个由我的对象和我的对象引用的所有对象(主要是类对象)组成的部署环境，即我的应用程序和所有依赖项。这就是虚拟机的工作方式。(我们的虚拟机写得太差了，我们需要在另一个Linux虚拟机上的VMWare虚拟机上在Linux虚拟机的Java虚拟机上运行Spring虚拟机，这是软件开发愚蠢的另一个例子)。当依赖项得到更新时，环境很容易提示开发人员将旧代码合并到新的库，使用新的库将代码合并到旧版本，或者保留两个版本。提示鼓励开发人员进行一些必要的轻微修改，以避免每个库都有20个版本，而像Maven这样的工具则隐藏了你有20个版的事实，并导致Java应用程序中常见的大量运行时膨胀。
在Java开发领域，Eclipse最接近于成为一个合适的对象环境，尽管有很多插件以各种方式打破了这种模式。大多数给出的使用Maven的理由在经过严格审查后都会分崩离析。
Netbeans和Idea是夸大其词的文本编辑器，而不是对象环境，但如果你确实想将它们的工具用于数千个Eclipse插件所没有涵盖的内容，它们都可以导入和维护Eclipse项目，那么与使用Eclipse的开发人员相比，你的构建将非常缓慢，但如果它们是纯Netbeans或Idea项目，那么它们就会非常缓慢。
使用Maven并不是一个严肃的理由。
Eclipse中导出/导入设置的方便性(在任何情况下，每个团队都应该在任何IDE中做这件事)使得不同的设置问题只不过是开发团队的懒惰(或者关于空格与制表符的宗教争论，哈哈)。
同样，使用Maven并不是一个严肃的理由。
团队环境？向我展示一个尚未使用像GIT或SVN这样的存储库的团队。为什么我们需要通过设置Nexus repos来复制功能和维护难题？
这实际上是NOT使用Maven的一个很好的理由。
运行服务器生成？好主意，现在，这不应该由实际签入源repo的代码来启动吗，而不是由碰巧被推到Nexus的随机构建来启动吗？这就引出了对Git的一点，尤其是带有Maven的Git。由于在Git中，我不在分支上工作，在本地测试，然后提交(部分原因是由于Jenkins和Eclipse中Maven配置的差异，我的本地测试无法证明服务器构建有效)，我必须将我的更改提交到另一个分支，以查看服务器Maven构建失败，然后提交进一步的更改来解决问题，导致回购中的源历史记录不可读。签入的代码至少应该构建并通过单元测试，如果Git和Maven不在其中，就应该保证这一点。
如果你真的研究过的话，从Eclipse导出无头构建是很简单的——你只需要ant或Gradle，Eclipse已经维护的开发人员构建，以及一些Eclipse jar(Eclipse会将无头构建所需的所有文件导出到目录或zip文件，或者将它们ftp到构建服务器)。像Hudson/Jenkins这样的服务器构建工具可以从大多数源repos中提取更新的代码，并调用任何构建脚本，不依赖Maven。使用Maven，你要么强迫开发人员使用一种不适合任何人的工具，只适合构建工程师(构建所需的时间，即使使用M2E，也足以满足这种情况)，要么你生活在服务器构建无法像工作站构建那样工作的可能性中，如果你使用过多的M2E插件来集成两者，那么仍然是。无论哪种方式，你都会得到一个更慢、更脆弱的工作站构建，以获得一个同样缓慢、更加脆弱的服务器构建。在我工作过的每个基于Maven的项目中，我都看到过短暂的Hudson/Jenkins错误，这些错误不会出现在Eclipse中，除非你安装并正确配置了所有可能的M2E插件，而大多数开发人员从来没有这样做过。
这似乎是避免Maven的另一个好理由。
这并没有涵盖Maven的一些更基本的问题，比如它的名称空间破坏了Java名称空间和XML名称空间，它的构建单元(POM)与实际部署环境中的任何东西都没有关系(想想看，当你通过POM分离时，你在成品中实际完成了什么？什么都没有。它所完成的只是一种错误的感觉，即你已经将关注点和功能分为不同的构建单元，所有都作为一个整体代码运行)；手动维护复杂配置文件的麻烦，如果你碰巧需要使用OSGi或另一个容器，并且必须维护影响Maven配置的其他配置文件，而对它没有什么明显的意义，这种情况只会变得更糟；在没有完整的代码执行环境的情况下尝试运行单元测试所引起的问题；无数版本的依赖项，还有Maven特定的插件(我实际上在Maven构建本身中看到过JAR地狱，其中多个Maven插件使用冲突的依赖项-Maven应该解决的问题之一。
是的，可以使用Maven构建对象代码。你也可以用C甚至汇编程序编写纯对象代码，但我不知道你为什么要这样做。
避免Maven的最好原因是，当你厌倦了上面提到的所有问题(以及许多其他没有提到的问题)时，需要大量的工作来取消一组项目的专业化。
从C开发中继承下来的思维方式，即开发周期由编写代码、编译、组装、构建、部署、测试、重做组成，在对象环境中已经过时了。在某个时候，我们需要告诉所有有这种心态的人，他们需要重新学习如何发展。这样做将消除对Maven、Git和许多其他只会浪费时间的工具的任何需求。
对象开发应该在活动对象环境中进行，在该环境中，由于修改后的对象是活动的，所以在保存代码时会对代码更改进行测试。部署应该包括从该环境中删除仅用于开发的工件，创建一个运行时，该运行时拥有运行中的应用程序在开发和测试中使用的一切。
我目前正在处理一个使用maven程序集插件为OSGi应用程序创建部署程序集所引起的问题。该应用程序在Eclipse环境中运行良好，Eclipse环境将所有代码更改热部署到环境中运行的OSGi容器中。然而，尽管有一位非常优秀的配置/构建工程师，他的唯一工作就是完成这个过程，但配置并不能在maven组装过程中完好无损地保存下来。如果我们去掉Maven(由于代码量的原因，现在非常困难，但有可能)并使用BNDTOOLS Eclipse插件，我们可以简单地将Eclipse构建导出为Ant或Gradle无头构建(请注意，编写BND和BNDTOOLS的OSGi开发人员不支持Maven，而且出于充分的原因，Maven插件是由Felix开发人员编写的，他们自己使用Netbeans和Maven，除了部署周期结束时没有其他活动环境)，在这两个工具中，都设置了与Eclipse相同的环境，而没有只针对开发人员的GUI对象。结果将是用于部署的相同配置和构建。这将很容易为目前每个开发者每天节省2-3个小时观看缓慢的Maven或M2E构建，并释放配置/构建工程师在部署主机上对应用程序进行更多测试。
克服写/编译/组装/构建/部署/测试的心态是唯一的主要障碍。假装你在1979年的VT100终端上而不是在现代机器上编码并不能让你成为一个"真正的"开发人员，它只是表明你的方法已经过时35年了。
在团队中的开发人员中，没有一个能够充分理解Eclipse这样的实时对象环境，使其能够与M2E和OSGi一起作为实时环境工作，而且他们是顶级开发人员，只是由于过时的命令行开发工具的流行，他们还没有接触过它。他们只是在我们进行配对编程以解决配置问题时才意识到这是可能的，而我正在共享我的屏幕，当他看到我的代码更改立即在后台OSGi容器中进行测试时，其他团队成员惊呼"这就是你写代码的方式"。在必要的时候，我可以使用bash shell，比如当我在远程服务器上查看日志时，事实上，我这样做的效率相当高，这样我就可以尽快离开那个环境，回到21世纪。
使用Ant或Maven有很多优点。
Maven或多或少是Ant的一个更新概念。我决定用另一种方法来回答这个问题，而不是给你一个要点式的答案。我会问你一个简单的问题。我在这里假设你是一名开发人员；或者有某种OO编程背景。
因此，如果您的经理要求您复制200个目录，但忽略这些目录中的jar, war and ear文件并复制一次。然后将这200个目录部署到另一个目的地，但只部署.class文件；将其余文件复制到另一个目的地等。
让你用java来做这件事；它将是大量的逻辑，大量的代码，并且不可扩展或不适应变化。因此，请记住Ant或Maven将以较少的开销快速完成和准备所有这些，供您的应用程序使用。与Java相比，ant或Maven中的代码大小将是1/4。
点击链接获取更多技术优势：
Maven
Ant我找不到一个有好处的真实答案，但我相信这会说服你；)
Maven和Ant用于编写构建脚本，以便它们可以在批处理作业中执行，如使用Jenkins或在命令行上执行。
事实上，Eclipse本身广泛使用Ant来构建插件。
如果你要学习两者中的一个，学习Maven，这是现在几乎每个人都使用的(取代Ant)。
Maven通常用于为特定应用程序构建插件或jar。
假设您已经开发了一个应用程序，但不想手动添加该应用程序所需的jar。在这种情况下，Maven或Ant非常有帮助。一旦您编写了代码，只需运行方式->Maven Build(单击Maven Build)，它就会生成所有所需的插件或jar，并包含在您的应用程序库构建路径中。可能会有一个疑问，比如应用程序将如何获得这些jar。对于每个应用程序，都有一个名为POM.xml的xml文件，其中保存了所有jar的引用，以供下载。