我认为这个问题是Compare到Java的IDE的扩展，我们还需要Ant吗？
上面的问题有答案，但我想知道一个使用Maven或Ant而不是Eclipse的具体例子。
当我在Eclipse中开发时，Eclipse为我做所有事情，我只需要点击运行按钮。而且，Eclipse还可以让你将代码导出到一个可运行的jar中，甚至可以.exe windows。
所以我真的不知道为什么我需要Maven或Ant。
而且，如果我确实需要，我应该选择哪一个，Maven还是Ant？
Eclipse 是一个开发环境。但它不是一个构建工具。
我个人讨厌Maven，但YMMV。有许多替代方案：gradle，buildr等。
Maven 给我的印象是，一群过去按日期出售的 c-shell 脚本小子写的一些东西，他们认为 autoconf 是领先的代码自动化，并且不明白目标代码需要对象环境才能以任何方式有效地进行开发或部署。蚂蚁已经够糟糕的了，但Maven结合了蚂蚁和艾薇所有最糟糕的功能。它不会创建对象环境，并且不能很好地与这样做的工具配合使用。
简单地说，对象环境应该具有所有类对象，即确定系统可用的对象类型的对象，实时且始终可用。从那里，我可以做任何我想做的事情，实例化一个类的多个对象，设置各种序列和实例化规则，等等。由于环境应该完全实时，因此我根本不需要构建工具。在部署我的应用方面，环境不难简单地抛出组成我的应用的命名空间中的代码从未引用的所有类对象。今天，JVM 中的垃圾回收器在运行中几乎执行相同的操作。在这一点上，我有一个部署环境，由我的对象和我的对象引用的所有对象（主要是类对象）组成，即我的应用程序和所有依赖项。这就是虚拟机的工作方式。（我们的虚拟机写得很糟糕，我们需要在Java虚拟机上运行Spring VM，在另一个Linux VM上运行VMWare VM，这是软件开发愚蠢的另一个例子）。当依赖项更新时，环境可以很容易地提示开发人员将旧代码合并到新库，将使用新库的代码合并到旧版本，或保留两个版本。提示鼓励开发人员进行轻微的修改，这些修改有时是必要的，以避免每个库都有二十个版本，而像Maven这样的工具则隐藏了你有二十个版本的事实，并导致Java应用程序中常见的大量运行时膨胀。
在Java开发领域，Eclipse最接近于成为一个合适的对象环境，尽管有很多插件以各种方式打破了范式。使用Maven给出的大多数原因在批判性检查时都会分崩离析。
Netbeans和Idea是夸大的文本编辑器，而不是对象环境，但是如果你确实想将他们的工具用于成千上万的Eclipse插件没有涵盖的东西，两者都可以导入和维护Eclipse项目，与使用Eclipse的开发人员相比，你的构建将非常慢，但是，如果它们是纯粹的Netbeans或Idea项目，它们就会那么慢。
这不是使用Maven的严肃理由。
在Eclipse中导出/导入设置的便利性（在任何情况下，每个团队在任何IDE中都应该这样做）使得不同的设置问题只不过是开发团队的懒惰（或者关于空格与制表符的宗教争论，哈哈）。
同样，这不是使用Maven的严肃理由。
团队环境？向我展示一个尚未使用 GIT 或 SVN 等存储库的团队。为什么我们还需要通过设置Nexus存储库来复制功能和维护难题？
这实际上是不使用Maven的一个很好的理由。
正在运行服务器版本？现在，好主意，这不应该由实际签入源存储库的代码开始，而不是碰巧被推送到Nexus的随机构建吗？这就引出了一个反对 Git 的观点，尤其是 Git 与 Maven。由于在 Git 中，我不在分支上工作，在本地测试，然后提交（部分原因是我的本地测试不能证明服务器构建是有效的，因为 Jenkins 和 Eclipse 中的 Maven 配置存在差异），我必须将我的更改提交到不同的分支，以便看到服务器 Maven 构建失败，然后提交进一步的更改来解决问题， 导致存储库中的源历史记录不可读。签入的代码至少应该构建并通过单元测试，如果Git和Maven不在画面中，应该保证这一点。
如果你真的研究一下，从Eclipse导出一个无头构建是微不足道的 - 你所需要的只是蚂蚁或Gradle，已经由Eclipse维护的开发人员构建，以及一些Eclipse jar（Eclipse会将无外设构建所需的所有文件导出到目录或zip文件，或者将它们ftp导出到构建服务器）。像Hudson/Jenkins这样的服务器构建工具可以从大多数源存储库中提取更新的代码并调用任何构建脚本，而不依赖于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-assembly 插件为 OSGi 应用创建部署程序集所导致的问题。该应用程序在Eclipse环境中完美运行，Eclipse环境将所有代码更改热部署到环境中正在运行的OSGi容器中。然而，配置在maven组装过程中并不能完整地存活下来，尽管有一个非常好的配置/构建工程师，他的唯一工作就是完成该过程。如果我们摆脱了Maven（由于代码量很大，现在非常困难，但有可能），并使用BNDTOOLS Eclipse插件，我们可以简单地将Eclipse版本导出为Ant或Gradle无头构建（注意，编写BND和BNDTOOLS的OSGi开发人员不支持Maven，并且有充分的理由，Maven插件是由Felix开发人员编写的，他们自己使用Netbeans和Maven， 除了在部署周期结束时之外，没有其他实时环境），其中两个工具都设置了与Eclipse相同的环境，而没有GUI对象，无论如何，GUI对象仅适用于开发人员。结果将是相同的配置和部署构建。这样，每个开发人员每天可以轻松节省 2-3 个小时，目前用于监视缓慢的 Maven 或 M2E 构建，并释放配置/构建工程师，以便在部署主机上对应用进行更多测试。
克服编写/编译/汇编/构建/部署/测试的思维方式是唯一的主要障碍。假装你在1979年的VT100终端上编码，而不是现代机器，并不能让你成为一个“真正的”开发人员，它只是表明你的方法已经过时了35年。
在团队中的开发人员中，没有一个人正确地理解像Eclipse这样的实时对象环境，足以让它作为M2E和OSGi的实时环境工作，他们是顶级开发人员，他们只是没有接触到它，因为过时的命令行开发工具的流行。他们直到意识到，当我们进行结对编程以解决配置问题时，这是可能的，而我正在共享我的屏幕，导致其他团队成员之一惊呼“这就是你写代码的方式如此之快”，当他看到我的代码更改立即在后台OSGi容器中测试自己时。我可以在必要时使用bash shell，例如当我在远程服务器上查看日志时，实际上我这样做相当有效，这样我就可以尽快离开那个环境并回到21世纪。
