为什么我们需要Maven或Ant，如果我们已经有Eclipse了？
我想这个问题是比较Java的IDE的扩展，我们还需要Ant吗？
有关于上述问题的答案，但我想知道一个使用Maven或Ant只是Eclipse的具体例子。
当我在Eclipse中开发时，Eclipse为我做了一切，我只需要点击运行button。 而且，Eclipse可以让你将你的代码导出到一个可运行的jar甚至windows的.exe文件中。
所以我真的不知道为什么我需要Maven或Ant。
而且，如果我需要， 我应该select哪一个，Maven还是Ant？
- 因为你的同事可能更喜欢NetBeans或IDEA
- 因为这些设置可能会从一个安装到另一个安装
- 因为你可能想自动获得你的依赖关系
- 因为要自动化完整的构build：构build，jar，应用静态代码分析，运行unit testing，生成文档，复制到某个目录，根据环境调整某些属性等。
- 因为一旦自动化，您可以使用持续集成系统在每次更改或每个小时build立应用程序，以确保一切仍然build立，testing仍然通过…
- 因为Maven使用约定而不是configuration。
- 因为你的IDE可能不支持你需要的一些奇特的代码生成/转换。
- 因为构build脚本logging了构build过程。
Eclipse是一个开发环境。 但它不是一个构build工具。
我个人讨厌Maven，但是YMMV。 有很多select：gradle，buildr等
Maven让我想起了一大堆过时的c-shell脚本编写者，他们认为autoconf是前沿代码自动化，并且不理解目标代码需要一个对象环境任何方式有效的开发或部署。 ant已经够糟糕了，但是Maven结合了Ant和Ivy的所有最糟糕的function。 它不会创build一个对象环境，并且不适合使用它的工具。
简而言之，对象环境应该包含所有的类对象，即确定系统可用对象types的对象，它们始终处于活动状态和可用状态。 从那里我可以做任何我想做的，实例化一个类的多个对象，设置各种序列和实例化规则等。由于环境应该是完全活的，我根本不需要构build工具。 就部署我的应用程序而言，环境并不难于简单地将构成我的应用程序的名称空间中的代码从未引用的所有类对象全部抛出。 JVM中的垃圾收集器在今天几乎完成了同样的事情。 在这一点上，我有一个由我的对象和我的对象引用的所有对象（主要是类对象）组成的部署环境，即我的应用程序和所有的依赖关系。 这是虚拟机的工作原理。 （我们的虚拟机写得太差了，我们需要在另一台Linux VM上的VMWare虚拟机上的Linux VM上的Java VM上运行Spring VM，这是软件开发的另一个例子）。 当依赖关系得到更新时，环境提示开发人员将他的旧代码合并到新的库中，将新的库代码合并到旧版本，或者同时保留两个版本。 提示鼓励开发人员进行微小的修改，以避免每个库有二十个版本，而像Maven这样的工具隐藏了你有二十个版本的事实，并导致Java应用程序中常见的大量运行时膨胀。
在Java开发领域，Eclipse最接近于适当的对象环境，尽pipe有许多插件以各种方式打破范例。 使用Maven的大多数原因在批判性地检查时都崩溃了。
Netbeans和Idea是被夸大的文本编辑器，而不是对象环境，但是如果你想要使用他们的工具来处理成千上万的Eclipse插件所没有涉及的东西，那么他们都可以导入和维护Eclipse项目，与开发者相比，使用Eclipse，但是，如果他们是纯粹的Netbeans或Idea项目，他们会很慢。
不是使用Maven的严重原因。
Eclipse中导出/导入设置的简易性（任何情况下，每个团队都应该在任何IDE中执行）使得不同的设置问题不仅仅是开发团队的懒惰（或者是关于空间与标签的宗教争论，lol） 。
再次，不是使用Maven的严重原因。
团队环境？ 向我展示一个尚未使用GIT或SVN等存储库的团队。 为什么我们需要通过设置Nexus回购来复制function和维护头痛呢？
这实际上是一个不使用Maven的好理由。
运行服务器构build？ 好的想法现在不应该被实际签入到源代码库的代码而不是被推到Nexus的随机构build所启动？ 这提出了一个反对Git的一点，特别是与Maven的Git。 因为在Git中，我不在分支上工作，在本地testing，然后提交（部分原因是我的本地testing不能certificate服务器构build工作，因为Jenkins和Eclipse中的Mavenconfiguration的差异），我必须提交我的更改一个不同的分支为了看到服务器Maven构build失败，然后提交进一步的修改来解决问题，导致在repo中的源代码不可读。 检查代码应该至lessbuild立并通过unit testing，如果Git和Maven超出了图片应该保证。
从Eclipse导出无头构build是微不足道的，如果你真的关注它 – 你需要的只是ant或者Gradle，已经由Eclipse维护的开发者构build，以及一些Eclipse jar（Eclipse会将所有必要的文件导出到无头构build目录或zip文件，或者ftp到构build服务器）。 像Hudson / Jenkins这样的服务器构build工具可以从大多数源代码仓库中提取更新后的代码，并调用任何构build脚本，而不依赖于Maven。 有了Maven，你要么迫使开发人员使用一个不适合任何人的工具，而要build立工程师（即使使用M2E，构build所需的时间也就足够了），否则你就可能生成服务器并不像工作站构build那样工作，如果使用过多的M2E插件整合这两者的麻烦，这仍然是事实。 无论哪种方式，你会得到一个更慢，更脆弱的工作站构build，为了同样缓慢和更脆弱的服务器构build。 在每一个基于Maven的项目中，我都曾经看到暂时的Hudson / Jenkins错误，除非你已经完全安装了所有可能的M2E插件并且正确configuration，否则绝大多数开发者从来都不会这样做。
似乎是避免Maven的另一个重要原因。
这不包括Maven的一些更基本的问题，比如它的命名空间打破了Java命名空间和XML命名空间，它的构build单元（POM）与实际部署环境中的任何东西都没有任何关系（想想看，当你分开通过POM，你在成品中实际完成了什么？没有什么，它所完成的只是一种错觉，你已经将关注点和function分离到不同的构build单元中，所有的构build单元都作为一个整体代码运行）。 手动维护复杂configuration文件的麻烦，如果您碰巧需要使用OSGi或其他容器，并且必须维护其他影响Mavenconfiguration且受其影响的configuration文件，则这种configuration文件只会变得更糟。 在没有完整的代码执行环境的情况下尝试运行unit testing引起的问题; 无数的版本不仅依赖于Maven特定的插件（我实际上已经看到了Maven中的JAR地狱，它构build了多个Maven插件使用冲突的依赖关系 – 这是Maven应该解决的问题之一。
是的，你可以用Maven构build目标代码。 你也可以用C语言编写纯粹的目标代码，甚至是汇编语言，但是我不知道你为什么要这么做。
避免Maven的最好的理由是当你厌倦了上面提到的所有问题（以及许多其他未提到的问题）时，为一组项目取消configuration所需的大量工作。
从C开发inheritance下来的思维模式，在编程，编译，汇编，构build，部署，testing，重做等开发周期中，在对象环境中是绝望的过时的。 在某种程度上，我们需要用这种心态告诉所有的人，他们需要重新学习如何发展。 这样做可以消除对Maven，Git和其他许多工具的需求，而这些工具只是浪费时间。
对象开发应该在活动对象环境中完成，在该对象环境中，由于修改的对象是活动的，所以在保存代码更改时会对其进行保存。 部署应包括从该环境中仅删除开发人工制品，创build一个运行时，运行应用程序在开发和testing中使用的一切。
我目前正在处理使用maven-assembly插件为OSGi应用程序创build部署程序集所导致的问题。 该应用程序在Eclipse环境中完美工作，该环境将所有代码更改部署到环境中正在运行的OSGi容器中。 然而，尽pipe拥有一个非常好的configuration/构build工程师，他们的唯一工作就是完成这个过程，但是configuration在maven组装过程中并不能完好无损。 如果我们摆脱了Maven（由于代码量太大，现在非常困难，但是可能），并且使用了BNDTOOLS Eclipse插件，我们可以简单地将Eclipse构build导出为Ant或者Gradle无头版本（注意，编写BND的OSGi开发者和BNDTOOLS 不支持Maven，出于很好的理由，Maven插件是由Felix开发人员编写的，他们自己使用Netbeans和Maven，除了部署周期结束之外，没有其他的实时环境），其中两个工具设置相同环境作为Eclipse，而不包含仅供开发人员使用的GUI对象。 结果将是一个相同的configuration和构build部署。 这样每个开发人员每天可以节省2-3个小时，每个开发人员目前都在观看缓慢的Maven或M2E构build，然后释放configuration/构build工程师在部署主机上执行更多的应用程序testing。
克服写/编译/汇编/构build/部署/testing的思想是唯一的主要障碍。 假设你在一个1979年的VT100terminal上编码，而不是一个现代化的机器，这不会让你成为一个真正的开发者，它只是表明你的方法已经过时了35年。
在团队中的开发人员中，其他人都没有正确理解像Eclipse这样的实时对象环境，以使其能够像M2E和OSGi那样作为一个现场环境工作，他们是顶级开发人员，他们只是没有接触到到过时的命令行开发工具的stream行。 当我们结对编程解决configuration问题时，他们才意识到这是可能的 ，我分享了我的屏幕，导致其他团队成员之一惊叹“ 这就是你如何快速写代码”，当他看到我的代码更改立即在后台OSGi容器中testing自己。 当我需要的时候，我可以使用bash shell，例如当我在远程服务器上查看日志时，事实上我可以非常高效地完成这项工作，所以我可以尽快摆脱这种环境，回到第21步世纪。
使用Ant或Maven有很多好处。
Maven或多或less是Ant的更新概念。 我决定采取另一种方法来回答这个问题，而不是给你一个重点答案。 我会问你一个简单的问题。 我假设你是开发者， 或者有某种OO编程背景。
所以如果你的经理要求你复制两百个目录，但是忽略这些目录中的jar, war and ear文件，并且一旦被复制。 然后，您将这两百个目录部署到另一个目标，但只部署.class文件; 将其余的文件复制到另一个目的地等
对于你在java中这样做; 这将是很多的逻辑，大量的代码，将不会扩展或适应改变。 因此，考虑到Ant或Maven将会以更less的开销为您的应用程序使用而完成并准备好所有这些内容。 ant或Maven中的代码大小将是Java的1/4 。
点击链接获得更多技术优势：
Maven的
ant我找不到一个真正的答案，但我相信这会说服你;）
Maven和Ant用于构build脚本，以便可以像Jenkins或命令行一样执行批处理作业。
事实上，Eclipse本身使用Ant来构build插件。
如果你要学习其中的一个，那么学习Maven，这是几乎每个人现在使用的（代替Ant）。
Maven通常用于构build特定应用程序的插件或jar子。
假设你已经开发了一个应用程序，但你不想去手动添加该应用程序所需的jar子。 在这种情况下，Maven或Ant很有帮助。 一旦你写了你的代码只需要运行 – > Maven Build（点击Maven Build），它将生成所有必需的插件或jar，并包含在你的应用程序库构buildpath中。 一个疑问可能会像应用程序如何获得这些jar子，每个应用程序都有一个名为POM.xml的XML文件，其中所有jar子的引用保留在那里用于下载目的。
