I think this question is an extension of Compare to the IDE for Java,do we still need Ant?
我认为这个问题是对Java的IDE的一个扩展，我们还需要Ant吗?
There are answers for the question above, but I wish to know a concrete example of using Maven or Ant over just Eclipse.
上面的问题有答案，但是我希望知道使用Maven或Ant而不是Eclipse的具体示例。
When I develop in Eclipse, Eclipse does everything for me and I just need to click the run button. And also, Eclipse can let you export your code to a runnable jar or even .exe for windows.
当我在Eclipse中开发时，Eclipse为我做了一切，我只需要点击run按钮。此外，Eclipse还允许您将代码导出到可运行的jar甚至windows的.exe中。
So I really don't know why I need Maven or Ant.
所以我真的不知道为什么我需要Maven或Ant。
And also if I do need, which one should I choose, Maven or Ant?
如果我确实需要，我应该选择哪个，Maven还是Ant?
5 个解决方案
#1
78
- Because your collegue might prefer NetBeans or IDEA
- 因为你的同事可能更喜欢NetBeans或IDEA
- Because the settings might vary from one eclipse install to another
- 因为不同的eclipse安装会有不同的设置
- Because you might want to get your dependencies automatically
- 因为您可能希望自动获得依赖项。
- Because you want to automate the complete build: build, jar, apply static code analysis, run the unit tests, generate the documentation, copy to some directory, tune some properties depending on the environment, etc.
- 因为您希望自动化完整的构建:构建、jar、应用静态代码分析、运行单元测试、生成文档、复制到某个目录、根据环境调整某些属性等等。
- Because once it's automated, you can use a continuous integration system which builds the application at each change or every hour to make sure everything still builds and the tests still pass...
- 因为一旦它被自动化，您可以使用一个持续集成系统，在每次更改或每小时构建应用程序，以确保所有内容仍然构建，并且测试仍然通过……
- Because Maven uses convention over configuration.
- 因为Maven使用约定而不是配置。
- Because your IDE may not support some fancy code generation/transformation you need.
- 因为您的IDE可能不支持您需要的一些花哨的代码生成/转换。
- Because a build script documents the build process.
- 因为构建脚本记录构建过程。
Eclipse is a development environment. But it's not a build tool.
Eclipse是一个开发环境。但它不是构建工具。
I personally hate Maven, but YMMV. There are many alternatives: gradle, buildr, etc.
我个人讨厌Maven，但是YMMV。有很多选择:等级，建造等等。
#2
11
Maven strikes me as a case of something written by a bunch of past-their-sell-by-date c-shell script kiddies who think autoconf is leading edge code automation and don't understand that object code requires an object environment to be in any way efficient either for development or deployment. Ant was bad enough, but Maven combines all the worst features of Ant and Ivy. It doesn't create an object environment, and it doesn't play well with tools that do.
Maven给我的印象是，它是由一群过去的-他们的-销售- - -shell脚本孩子编写的，他们认为autoconf是最先进的代码自动化，并且不理解对象代码要求对象环境在开发或部署方面具有任何效率。Ant已经够糟糕了，但是Maven综合了Ant和Ivy最糟糕的特性。它不创建对象环境，也不能很好地使用具有此功能的工具。
Simply, an object environment should have all class objects, i.e. the objects that determine the types of objects available to the system, live and available at all times. From there I can do whatever I want, instantiate multiple objects of a class, set up various sequences and instantiation rules, etc. Since the environment should be completely live, I shouldn't need a build tool at all. In terms of deploying my app, it's not difficult for the environment to simply throw out all the class objects that are never referenced by code in the namespaces that make up my app. The garbage collector in the JVM does almost the same thing on the fly today. At that point I have a deployment environment made up of my objects and all the objects (primarily class objects) that my objects reference, i.e. my application and all dependencies. This is how virtual machines work. (that our VMs are so poorly written we need to run a Spring VM on a Java VM on a Linux VM on a VMWare VM on another Linux VM is another example of the idiocy of software development). When dependencies get updated, it's simple enough for the environment to prompt the developer to merge his old code to the new libs, merge the code using the new libs down to the older version, or keep both versions. Prompting encourages the developer to make the slight modifications that are sometimes necessary to avoid having twenty versions of every library, while tools like Maven hide the fact that you have twenty versions and result in the massive runtime bloat common in Java apps.
简单地说，对象环境应该包含所有类对象，即确定系统可用对象类型的对象，这些对象是活动的，并且一直可用。从那里，我可以做任何我想做的事情，实例化一个类的多个对象，建立各种序列和实例化规则，等等。在部署我的应用程序时，环境简单地抛出所有类对象，这些类对象在构成我的应用程序的名称空间中从未被代码引用过。此时，我有一个部署环境，由我的对象和我的对象引用的所有对象(主要是类对象)组成，也就是我的应用程序和所有依赖项。这就是虚拟机的工作原理。(我们的VM写得很糟糕，我们需要在Java VM上运行Spring VM，在Linux VM上运行Spring VM，在另一个Linux VM上运行VMWare VM，这是软件开发白痴的另一个例子)。当依赖关系得到更新时，环境非常简单，可以促使开发人员将他的旧代码合并到新的libs中，并将新代码合并到旧版本中，或者保留两个版本。提示鼓励开发人员进行一些微小的修改，这些修改有时是为了避免每个库都有20个版本，而像Maven这样的工具隐藏了您有20个版本的事实，并导致Java应用程序中大量运行时膨胀。
In the Java development space Eclipse comes closest to being a proper object environment, although granted there are plenty of plugins that break the paradigm in various ways. Most of the reasons given for using Maven fall apart when examined critically.
在Java开发空间中，Eclipse最接近于成为一个合适的对象环境，尽管有许多插件以各种方式打破了这种模式。在严格检查时，使用Maven的大多数理由都不成立。
Netbeans and Idea are overblown text editors, not object environments, but if you do want to use their tools for something not covered by the thousands of Eclipse plugins, both can import and maintain Eclipse projects, your build will just be inordinately slow compared to developers using Eclipse, but then, they'd be that slow if they were pure Netbeans or Idea projects anyway.
Netbeans和想法被夸大了文本编辑器,而不是对象的环境,但是如果你想使用他们的工具,一些未被成千上万的Eclipse插件,可以导入和维护Eclipse项目,您的构建将是非常地缓慢相比,开发人员使用Eclipse,但是,他们会缓慢如果纯粹的Netbeans或想法项目。
Not a serious reason to use Maven.
使用Maven并不是一个严肃的理由。
The ease of exporting / importing settings in Eclipse (something every team should do in any IDE in any case) makes the different settings problem nothing more than laziness on the part of the development team (or a religious argument over spaces vs tabs, lol).
Eclipse中导出/导入设置的简单性(每个团队在任何情况下都应该做的事情)使得不同的设置问题仅仅是开发团队的懒惰(或者是关于空间vs选项卡的宗教争论)。
Again, not a serious reason to use Maven.
同样，使用Maven也不是一个严肃的理由。
Team environment? Show me a team that doesn't already use a repository like GIT or SVN. Why do we need to duplicate both the functionality and the maintenance headache by setting up Nexus repos as well?
团队环境?向我展示一个尚未使用GIT或SVN之类存储库的团队。为什么我们需要通过设置Nexus repos来复制功能和维护方面的麻烦呢?
That one's actually a good reason NOT to use Maven.
这是一个不使用Maven的好理由。
Running a server build? Great idea, now, shouldn't that be kicked off by code that's actually checked in to the source repo rather than a random build that happens to get pushed to Nexus? This brings up a point against Git, particularly Git with Maven. Since in Git I don't work on a branch, test locally, then commit (partly because my local test doesn't prove the server build works due to differences in the Maven configuration in Jenkins and Eclipse) I have to commit my changes to a different branch in order to see that the server Maven build fails, then commit a further change to fix the problem, resulting in an unreadable source history in the repo. Checked in code should at the very least build and pass unit tests, which if Git and Maven were out of the picture should be guaranteed.
运行一个服务器建立?好主意，现在，不应该被真正的代码检查，而不是一个随机生成的，被推送到Nexus的代码吗?这给Git带来了一个问题，尤其是与Maven的Git。因为在Git中我不工作在树枝上,在本地测试,然后提交(部分原因是我本地测试并不能证明服务器构建作品由于差异Maven配置在詹金斯和Eclipse)我要提交我的更改到另一个分支为了看到服务器Maven构建失败,然后提交进一步改变解决这个问题,从而导致一个不可读源码回购历史。检入的代码至少应该能够构建并通过单元测试，如果Git和Maven不存在，那么就应该保证通过单元测试。
Exporting a headless build from Eclipse is trivial if you actually look into it - all you need is ant or Gradle, the developer build already maintained by Eclipse, and a few Eclipse jars (Eclipse will export all the necessary files for a headless build to a directory or zip file, or ftp them to the build server). Server build tools like Hudson/Jenkins can pull updated code from most source repos and call any build script, there's no dependency on Maven. With Maven you either force developers to use a tool not suited to anybody but build engineers (the magnitudes longer it takes to build, even using M2E, is sufficient for that case to be made), or you live with the possibility that the server build doesn't work quite like the workstation build, which is still true if you go through all the hassle of integrating the two using the plethora of M2E plugins. Either way you get a slower and more fragile workstation build for the sake of an equally slow and more fragile server build. On every Maven based project I've worked on I've seen transient Hudson/Jenkins errors that don't show up in Eclipse unless you have absolutely every possible M2E plugin installed and correctly configured, and most developers never do.
出口一个无头构建从Eclipse很简单如果你看着它,你所需要的是ant或Gradle,开发人员构建已经由Eclipse,和一些Eclipse jar(Eclipse将导出所有必要的文件一个无头建立一个目录或zip文件,或ftp构建服务器)。像Hudson/Jenkins这样的服务器构建工具可以从大多数源代码repos中提取更新后的代码并调用任何构建脚本，并不依赖于Maven。Maven你要么迫使开发人员使用的工具不适合任何人但构建工程师(大小不再需要构建,甚至使用M2E,足以让这种情况了),或者你生活与服务器建立的可能性并不很喜欢工作站构建工作,仍然是真实的如果你经历所有的麻烦使用过多的M2E集成这两个插件。无论哪种方式，您都会得到一个速度更慢、更脆弱的工作站构建，因为服务器构建同样慢，也更脆弱。在我所研究的每个基于Maven的项目中，我都遇到过短暂的Hudson/Jenkins错误，这些错误不会在Eclipse中出现，除非您安装并正确配置了所有可能的M2E插件，而且大多数开发人员都不会这样做。
Seems like another great reason to avoid Maven.
似乎是另一个避免Maven的好理由。
That doesn't cover some of the more fundamental problems with Maven, such as its namespaces breaking Java namespaces and XML namespaces, it's build unit (the POM) having no relation to anything in the actual deployment environment (think about it, when you separate via POMs what are you actually accomplishing in the finished product? Nothing. All it accomplishes is a false sense that you've separated concerns and functionality into different build units that all run as one monolithic piece of code); the hassle of manually maintaining complex configuration files, which only gets worse if you happen to need to use OSGi or another container and have to maintain other config files that affect and are affected by the Maven config with very little obvious sense to it; the problems caused by trying to run unit tests without a full environment for the code to execute in; the myriad versions not only of dependencies but of Maven specific plugins (I've actually seen JAR hell in the Maven build itself where multiple Maven plugins were using conflicting dependencies - one of the problems Maven was supposed to solve.
不包括与Maven一些更基本的问题,如它的名称空间破坏Java名称空间和XML名称空间,它的构建单元(POM)没有任何实际的部署环境的关系(想想,当你单独通过酸盐实际上完成的成品是什么?什么都没有。它所实现的只是一种错误的感觉，即您将关注点和功能分离到不同的构建单元中，这些构建单元都作为一个整体代码运行);手动维护复杂配置文件的麻烦，只有当您需要使用OSGi或其他容器，并且需要维护其他影响和受Maven配置影响的配置文件时，这种麻烦才会变得更糟，而且对Maven配置的意义非常小;在没有完整的代码执行环境的情况下运行单元测试导致的问题;无数的版本不仅依赖于依赖关系，还包括Maven特定的插件(我实际上在Maven中看到了JAR hell，在那里，多个Maven插件使用相互冲突的依赖关系——这是Maven应该解决的问题之一。
Yes, you can build object code with Maven. You can also write pure object code in C or even assembler, but I don't know why you'd want to.
是的，您可以使用Maven构建对象代码。您也可以用C甚至汇编程序编写纯对象代码，但是我不知道您为什么要这样做。
The best reason to avoid Maven is the phenomenal amount of work required to de-mavenize a set of projects when you get sick of all the problems noted above (and numerous others not mentioned).
避免使用Maven的最佳理由是，当您厌倦了上面提到的所有问题(以及许多其他未提到的问题)时，需要大量的工作来解除对一组项目的mavenize。
The mindset, inherited from C development, that the development cycle consists of write code, compile, assemble, build, deploy, test, do over again, is hopelessly outdated in an object environment. At some point we need to tell all the people with this mindset that they need to relearn how to develop, period. Doing so would remove any need for Maven, Git, and a host of other tools that do nothing but waste time.
从C开发继承而来的思维模式，即开发周期由编写代码、编译、组装、构建、部署、测试和重做组成，在对象环境中已经完全过时了。在某一时刻，我们需要告诉所有的人，他们需要重新学习如何发展。这样做将消除对Maven、Git和许多其他工具的任何需求，这些工具只会浪费时间。
Object development should be done in a live object environment, where a code change is tested as it is saved since the modified object is live. Deployment should consist of removing development only artefacts from that environment, creating a runtime that has everything used by the running app in development and test.
对象开发应该在一个活动的对象环境中完成，在这个环境中，由于修改后的对象是活的，代码更改被保存。部署应该包括从该环境中删除开发人员，创建一个运行时应用程序在开发和测试中使用的所有东西。
I'm currently dealing with a problem caused by creating deployment assemblies for an OSGi app using the maven-assembly plugin. The app works perfectly in the Eclipse environment, which hot deploys all code changes into a running OSGi container within the environment. However the configuration doesn't survive intact through the maven-assembly process, despite having a very good configuration/build engineer whose sole job is to accomplish that process. If we got rid of Maven (very difficult now due to the amount of code, but possible) and used the BNDTOOLS Eclipse plugin we could simply export the Eclipse build as an Ant or Gradle headless build (note, the OSGi developers who write BND and BNDTOOLS don't support Maven, and for good reason, the Maven plugin is written by the Felix developers who themselves use Netbeans and Maven, and no live environment other than at the end of the deploy cycle), where both tools set up the same environment as Eclipse, without the GUI objects that are only meant for developers anyway. The result would be an identical configuration and build for deployment. This would easily save 2-3 hours per day per developer currently spent watching slow Maven or M2E builds, and free up the config/build engineer to do more testing of the app on the deployment hosts.
我目前正在处理使用maven-assembly插件为OSGi应用程序创建部署程序集所引起的问题。该应用程序在Eclipse环境中工作得很好，Eclipse环境将所有代码更改部署到环境中运行的OSGi容器中。然而，配置在maven-assembly过程中不能完整地存在，尽管有一个非常好的配置/构建工程师，他的唯一工作就是完成这个过程。如果我们摆脱了Maven(非常困难现在由于代码的数量,但可能)和使用BNDTOOLS Eclipse插件我们可以简单地导出的Eclipse构建作为Ant或Gradle无头构建(注意,OSGi开发人员写BND BNDTOOLS不支持Maven,并有充分的理由,费利克斯写的Maven插件开发人员自己使用Netbeans和Maven,和任何生活环境最终部署周期),这两个工具都建立了与Eclipse相同的环境，没有GUI对象，而这些GUI对象只是为开发人员准备的。结果是相同的配置和部署构建。这将很容易地为每个开发人员节省每天2-3个小时的时间来观看缓慢的Maven或M2E构建，并释放配置/构建工程师在部署主机上进行更多的应用程序测试。
Getting over the mindset of write/compile/assemble/build/deploy/test is the only major impediment. Pretending you're coding on a 1979 VT100 terminal instead of a modern machine doesn't make you a 'real' developer, it just demonstrates that your methods are 35 years out of date.
克服编写/编译/组装/构建/部署/测试的思维模式是唯一的障碍。假设您是在1979年的VT100终端上编写代码，而不是在一台现代机器上编写代码，这并不意味着您是一个“真正的”开发人员，它只是表明您的方法已经过时了35年。
Of the developers on the team, none of the others properly understands a live object environment like Eclipse sufficiently to get it to work as a live environment with M2E and OSGi, and they are top developers, they just haven't been exposed to it due to the prevalence of outdated command line development tools. They only realized it was possible to do so when we were pair programming to solve the configuration problem and I was sharing my screen, causing one of the other team members to exclaim "that's how you write code so damn fast", when he saw my code change instantly test itself in the background OSGi container. I can use a bash shell when I have to, such as when I'm looking at logs on a remote server, in fact I do so fairly efficiently precisely so I can get out of that environment as quickly as possible and return to the 21st century.
开发人员的团队,没有一个人正确理解像Eclipse这样的活对象的环境足以让它工作作为生活环境M2E和OSGi,和他们是高级开发人员,他们只是没有接触它因普遍存在的过时的命令行开发工具。他们只意识到这么做当我们结对编程解决配置问题和我分享我的屏幕,导致其他团队成员之一惊叫“这就是你编写代码这么快”,当他看到我的代码变更立即测试本身在后台OSGi容器。我可以在必要的时候使用bash shell，比如当我查看远程服务器上的日志时，实际上我这样做的效率相当高，这样我就可以尽快离开这个环境，回到21世纪。
#3
5
There are soo many advantages to using Ant or Maven.
使用Ant或Maven有很多优点。
Maven is more or less an update concept of Ant. Instead of giving you a bullet point answer I have decided to take another approach into answering this question. I'll ask you a simple question. I'am assuming here that you would be a developer; or have some sort of OO programming background.
Maven或多或少是Ant的更新概念。我没有给你一个要点回答，而是决定采取另一种方法来回答这个问题。我要问你一个简单的问题。我假设你是一个开发人员;或者有一些OO编程的背景。
So If your manager was to ask you to copy two hundred directories, but ignore jar, war and ear files within those directories and once copied. You then deploy those two hundred directories to another destination but deploy only .class files; copy rest of the files into another destination etc.
因此，如果您的经理要求您复制200个目录，但是忽略jar、war和ear文件并在这些目录中进行复制。然后将这200个目录部署到另一个目的地，但只部署.class文件;将其余的文件复制到另一个目的地。
For you to do this in java; it will be lots of logic, lots of code and would not be extensible or adaptable to change. So that in mind Ant or Maven will accomplish and prepare all this on the fly with less overhead for your application to use. The size of the code in ant or Maven will be 1/4 compare to Java.
用java做这个;它将包含大量的逻辑、大量的代码，并且不能扩展或适应更改。因此，Ant或Maven将在您的应用程序使用的开销较小的情况下完成并准备所有这些工作。ant或Maven中的代码的大小将是Java的1/4。
Click on the links for more technical benefits:
点击链接获得更多的技术好处:
Maven
Ant I could not find an authentic answer with benefits, but I'm sure this would convince you ;)
我找不到可靠的答案，但我相信这能说服你;
#4
5
Maven and Ant are used to script builds so that they may be executed in batch jobs like with Jenkins or on the command line.
Maven和Ant用于脚本构建，以便它们可以像Jenkins或命令行那样在批处理作业中执行。
In fact Eclipse itself uses Ant extensively to build plugins.
事实上，Eclipse本身广泛地使用Ant来构建插件。
If you were to learn one of the two, learn Maven, it's the one pretty much everyone uses these days (replacing Ant).
如果你要学习其中的一个，学习Maven，这是当今几乎所有人都在使用的(取代Ant)。
#5
2
Maven is generally used to build the plugins or jars for a particular application.
Maven通常用于为特定的应用程序构建插件或jar。
Suppose you have developed an application but you don't want to go for adding the jars needed for that application manually. In this situation Maven or Ant is very helpful. Once you have written your code just got to Run As -> Maven Build (click on Maven Build) , it will generate all the required plugins or jars and include in your application library build-path. A doubt may come like how the application will get those jars, For each application there is a xml file named as POM.xml where reference of all the jars are kept there for downloading purposes.
假设您已经开发了一个应用程序，但您不希望手动添加该应用程序所需的jar。在这种情况下，Maven或Ant非常有用。一旦您编写了代码，并以-> Maven构建的形式运行(单击Maven构建)，它将生成所有必需的插件或jar，并在应用程序库构建路径中包含这些内容。人们可能会怀疑应用程序如何获得这些jar，因为每个应用程序都有一个名为POM的xml文件。将所有jar的引用保存在那里以便下载。
#1
78
- Because your collegue might prefer NetBeans or IDEA
- 因为你的同事可能更喜欢NetBeans或IDEA
- Because the settings might vary from one eclipse install to another
- 因为不同的eclipse安装会有不同的设置
- Because you might want to get your dependencies automatically
- 因为您可能希望自动获得依赖项。
- Because you want to automate the complete build: build, jar, apply static code analysis, run the unit tests, generate the documentation, copy to some directory, tune some properties depending on the environment, etc.
- 因为您希望自动化完整的构建:构建、jar、应用静态代码分析、运行单元测试、生成文档、复制到某个目录、根据环境调整某些属性等等。
- Because once it's automated, you can use a continuous integration system which builds the application at each change or every hour to make sure everything still builds and the tests still pass...
- 因为一旦它被自动化，您可以使用一个持续集成系统，在每次更改或每小时构建应用程序，以确保所有内容仍然构建，并且测试仍然通过……
- Because Maven uses convention over configuration.
- 因为Maven使用约定而不是配置。
- Because your IDE may not support some fancy code generation/transformation you need.
- 因为您的IDE可能不支持您需要的一些花哨的代码生成/转换。
- Because a build script documents the build process.
- 因为构建脚本记录构建过程。
Eclipse is a development environment. But it's not a build tool.
Eclipse是一个开发环境。但它不是构建工具。
I personally hate Maven, but YMMV. There are many alternatives: gradle, buildr, etc.
我个人讨厌Maven，但是YMMV。有很多选择:等级，建造等等。
#2
11
Maven strikes me as a case of something written by a bunch of past-their-sell-by-date c-shell script kiddies who think autoconf is leading edge code automation and don't understand that object code requires an object environment to be in any way efficient either for development or deployment. Ant was bad enough, but Maven combines all the worst features of Ant and Ivy. It doesn't create an object environment, and it doesn't play well with tools that do.
Maven给我的印象是，它是由一群过去的-他们的-销售- - -shell脚本孩子编写的，他们认为autoconf是最先进的代码自动化，并且不理解对象代码要求对象环境在开发或部署方面具有任何效率。Ant已经够糟糕了，但是Maven综合了Ant和Ivy最糟糕的特性。它不创建对象环境，也不能很好地使用具有此功能的工具。
Simply, an object environment should have all class objects, i.e. the objects that determine the types of objects available to the system, live and available at all times. From there I can do whatever I want, instantiate multiple objects of a class, set up various sequences and instantiation rules, etc. Since the environment should be completely live, I shouldn't need a build tool at all. In terms of deploying my app, it's not difficult for the environment to simply throw out all the class objects that are never referenced by code in the namespaces that make up my app. The garbage collector in the JVM does almost the same thing on the fly today. At that point I have a deployment environment made up of my objects and all the objects (primarily class objects) that my objects reference, i.e. my application and all dependencies. This is how virtual machines work. (that our VMs are so poorly written we need to run a Spring VM on a Java VM on a Linux VM on a VMWare VM on another Linux VM is another example of the idiocy of software development). When dependencies get updated, it's simple enough for the environment to prompt the developer to merge his old code to the new libs, merge the code using the new libs down to the older version, or keep both versions. Prompting encourages the developer to make the slight modifications that are sometimes necessary to avoid having twenty versions of every library, while tools like Maven hide the fact that you have twenty versions and result in the massive runtime bloat common in Java apps.
简单地说，对象环境应该包含所有类对象，即确定系统可用对象类型的对象，这些对象是活动的，并且一直可用。从那里，我可以做任何我想做的事情，实例化一个类的多个对象，建立各种序列和实例化规则，等等。在部署我的应用程序时，环境简单地抛出所有类对象，这些类对象在构成我的应用程序的名称空间中从未被代码引用过。此时，我有一个部署环境，由我的对象和我的对象引用的所有对象(主要是类对象)组成，也就是我的应用程序和所有依赖项。这就是虚拟机的工作原理。(我们的VM写得很糟糕，我们需要在Java VM上运行Spring VM，在Linux VM上运行Spring VM，在另一个Linux VM上运行VMWare VM，这是软件开发白痴的另一个例子)。当依赖关系得到更新时，环境非常简单，可以促使开发人员将他的旧代码合并到新的libs中，并将新代码合并到旧版本中，或者保留两个版本。提示鼓励开发人员进行一些微小的修改，这些修改有时是为了避免每个库都有20个版本，而像Maven这样的工具隐藏了您有20个版本的事实，并导致Java应用程序中大量运行时膨胀。
In the Java development space Eclipse comes closest to being a proper object environment, although granted there are plenty of plugins that break the paradigm in various ways. Most of the reasons given for using Maven fall apart when examined critically.
在Java开发空间中，Eclipse最接近于成为一个合适的对象环境，尽管有许多插件以各种方式打破了这种模式。在严格检查时，使用Maven的大多数理由都不成立。
Netbeans and Idea are overblown text editors, not object environments, but if you do want to use their tools for something not covered by the thousands of Eclipse plugins, both can import and maintain Eclipse projects, your build will just be inordinately slow compared to developers using Eclipse, but then, they'd be that slow if they were pure Netbeans or Idea projects anyway.
Netbeans和想法被夸大了文本编辑器,而不是对象的环境,但是如果你想使用他们的工具,一些未被成千上万的Eclipse插件,可以导入和维护Eclipse项目,您的构建将是非常地缓慢相比,开发人员使用Eclipse,但是,他们会缓慢如果纯粹的Netbeans或想法项目。
Not a serious reason to use Maven.
使用Maven并不是一个严肃的理由。
The ease of exporting / importing settings in Eclipse (something every team should do in any IDE in any case) makes the different settings problem nothing more than laziness on the part of the development team (or a religious argument over spaces vs tabs, lol).
Eclipse中导出/导入设置的简单性(每个团队在任何情况下都应该做的事情)使得不同的设置问题仅仅是开发团队的懒惰(或者是关于空间vs选项卡的宗教争论)。
Again, not a serious reason to use Maven.
同样，使用Maven也不是一个严肃的理由。
Team environment? Show me a team that doesn't already use a repository like GIT or SVN. Why do we need to duplicate both the functionality and the maintenance headache by setting up Nexus repos as well?
团队环境?向我展示一个尚未使用GIT或SVN之类存储库的团队。为什么我们需要通过设置Nexus repos来复制功能和维护方面的麻烦呢?
That one's actually a good reason NOT to use Maven.
这是一个不使用Maven的好理由。
Running a server build? Great idea, now, shouldn't that be kicked off by code that's actually checked in to the source repo rather than a random build that happens to get pushed to Nexus? This brings up a point against Git, particularly Git with Maven. Since in Git I don't work on a branch, test locally, then commit (partly because my local test doesn't prove the server build works due to differences in the Maven configuration in Jenkins and Eclipse) I have to commit my changes to a different branch in order to see that the server Maven build fails, then commit a further change to fix the problem, resulting in an unreadable source history in the repo. Checked in code should at the very least build and pass unit tests, which if Git and Maven were out of the picture should be guaranteed.
运行一个服务器建立?好主意，现在，不应该被真正的代码检查，而不是一个随机生成的，被推送到Nexus的代码吗?这给Git带来了一个问题，尤其是与Maven的Git。因为在Git中我不工作在树枝上,在本地测试,然后提交(部分原因是我本地测试并不能证明服务器构建作品由于差异Maven配置在詹金斯和Eclipse)我要提交我的更改到另一个分支为了看到服务器Maven构建失败,然后提交进一步改变解决这个问题,从而导致一个不可读源码回购历史。检入的代码至少应该能够构建并通过单元测试，如果Git和Maven不存在，那么就应该保证通过单元测试。
Exporting a headless build from Eclipse is trivial if you actually look into it - all you need is ant or Gradle, the developer build already maintained by Eclipse, and a few Eclipse jars (Eclipse will export all the necessary files for a headless build to a directory or zip file, or ftp them to the build server). Server build tools like Hudson/Jenkins can pull updated code from most source repos and call any build script, there's no dependency on Maven. With Maven you either force developers to use a tool not suited to anybody but build engineers (the magnitudes longer it takes to build, even using M2E, is sufficient for that case to be made), or you live with the possibility that the server build doesn't work quite like the workstation build, which is still true if you go through all the hassle of integrating the two using the plethora of M2E plugins. Either way you get a slower and more fragile workstation build for the sake of an equally slow and more fragile server build. On every Maven based project I've worked on I've seen transient Hudson/Jenkins errors that don't show up in Eclipse unless you have absolutely every possible M2E plugin installed and correctly configured, and most developers never do.
出口一个无头构建从Eclipse很简单如果你看着它,你所需要的是ant或Gradle,开发人员构建已经由Eclipse,和一些Eclipse jar(Eclipse将导出所有必要的文件一个无头建立一个目录或zip文件,或ftp构建服务器)。像Hudson/Jenkins这样的服务器构建工具可以从大多数源代码repos中提取更新后的代码并调用任何构建脚本，并不依赖于Maven。Maven你要么迫使开发人员使用的工具不适合任何人但构建工程师(大小不再需要构建,甚至使用M2E,足以让这种情况了),或者你生活与服务器建立的可能性并不很喜欢工作站构建工作,仍然是真实的如果你经历所有的麻烦使用过多的M2E集成这两个插件。无论哪种方式，您都会得到一个速度更慢、更脆弱的工作站构建，因为服务器构建同样慢，也更脆弱。在我所研究的每个基于Maven的项目中，我都遇到过短暂的Hudson/Jenkins错误，这些错误不会在Eclipse中出现，除非您安装并正确配置了所有可能的M2E插件，而且大多数开发人员都不会这样做。
Seems like another great reason to avoid Maven.
似乎是另一个避免Maven的好理由。
That doesn't cover some of the more fundamental problems with Maven, such as its namespaces breaking Java namespaces and XML namespaces, it's build unit (the POM) having no relation to anything in the actual deployment environment (think about it, when you separate via POMs what are you actually accomplishing in the finished product? Nothing. All it accomplishes is a false sense that you've separated concerns and functionality into different build units that all run as one monolithic piece of code); the hassle of manually maintaining complex configuration files, which only gets worse if you happen to need to use OSGi or another container and have to maintain other config files that affect and are affected by the Maven config with very little obvious sense to it; the problems caused by trying to run unit tests without a full environment for the code to execute in; the myriad versions not only of dependencies but of Maven specific plugins (I've actually seen JAR hell in the Maven build itself where multiple Maven plugins were using conflicting dependencies - one of the problems Maven was supposed to solve.
不包括与Maven一些更基本的问题,如它的名称空间破坏Java名称空间和XML名称空间,它的构建单元(POM)没有任何实际的部署环境的关系(想想,当你单独通过酸盐实际上完成的成品是什么?什么都没有。它所实现的只是一种错误的感觉，即您将关注点和功能分离到不同的构建单元中，这些构建单元都作为一个整体代码运行);手动维护复杂配置文件的麻烦，只有当您需要使用OSGi或其他容器，并且需要维护其他影响和受Maven配置影响的配置文件时，这种麻烦才会变得更糟，而且对Maven配置的意义非常小;在没有完整的代码执行环境的情况下运行单元测试导致的问题;无数的版本不仅依赖于依赖关系，还包括Maven特定的插件(我实际上在Maven中看到了JAR hell，在那里，多个Maven插件使用相互冲突的依赖关系——这是Maven应该解决的问题之一。
Yes, you can build object code with Maven. You can also write pure object code in C or even assembler, but I don't know why you'd want to.
是的，您可以使用Maven构建对象代码。您也可以用C甚至汇编程序编写纯对象代码，但是我不知道您为什么要这样做。
The best reason to avoid Maven is the phenomenal amount of work required to de-mavenize a set of projects when you get sick of all the problems noted above (and numerous others not mentioned).
避免使用Maven的最佳理由是，当您厌倦了上面提到的所有问题(以及许多其他未提到的问题)时，需要大量的工作来解除对一组项目的mavenize。
The mindset, inherited from C development, that the development cycle consists of write code, compile, assemble, build, deploy, test, do over again, is hopelessly outdated in an object environment. At some point we need to tell all the people with this mindset that they need to relearn how to develop, period. Doing so would remove any need for Maven, Git, and a host of other tools that do nothing but waste time.
从C开发继承而来的思维模式，即开发周期由编写代码、编译、组装、构建、部署、测试和重做组成，在对象环境中已经完全过时了。在某一时刻，我们需要告诉所有的人，他们需要重新学习如何发展。这样做将消除对Maven、Git和许多其他工具的任何需求，这些工具只会浪费时间。
Object development should be done in a live object environment, where a code change is tested as it is saved since the modified object is live. Deployment should consist of removing development only artefacts from that environment, creating a runtime that has everything used by the running app in development and test.
对象开发应该在一个活动的对象环境中完成，在这个环境中，由于修改后的对象是活的，代码更改被保存。部署应该包括从该环境中删除开发人员，创建一个运行时应用程序在开发和测试中使用的所有东西。
I'm currently dealing with a problem caused by creating deployment assemblies for an OSGi app using the maven-assembly plugin. The app works perfectly in the Eclipse environment, which hot deploys all code changes into a running OSGi container within the environment. However the configuration doesn't survive intact through the maven-assembly process, despite having a very good configuration/build engineer whose sole job is to accomplish that process. If we got rid of Maven (very difficult now due to the amount of code, but possible) and used the BNDTOOLS Eclipse plugin we could simply export the Eclipse build as an Ant or Gradle headless build (note, the OSGi developers who write BND and BNDTOOLS don't support Maven, and for good reason, the Maven plugin is written by the Felix developers who themselves use Netbeans and Maven, and no live environment other than at the end of the deploy cycle), where both tools set up the same environment as Eclipse, without the GUI objects that are only meant for developers anyway. The result would be an identical configuration and build for deployment. This would easily save 2-3 hours per day per developer currently spent watching slow Maven or M2E builds, and free up the config/build engineer to do more testing of the app on the deployment hosts.
我目前正在处理使用maven-assembly插件为OSGi应用程序创建部署程序集所引起的问题。该应用程序在Eclipse环境中工作得很好，Eclipse环境将所有代码更改部署到环境中运行的OSGi容器中。然而，配置在maven-assembly过程中不能完整地存在，尽管有一个非常好的配置/构建工程师，他的唯一工作就是完成这个过程。如果我们摆脱了Maven(非常困难现在由于代码的数量,但可能)和使用BNDTOOLS Eclipse插件我们可以简单地导出的Eclipse构建作为Ant或Gradle无头构建(注意,OSGi开发人员写BND BNDTOOLS不支持Maven,并有充分的理由,费利克斯写的Maven插件开发人员自己使用Netbeans和Maven,和任何生活环境最终部署周期),这两个工具都建立了与Eclipse相同的环境，没有GUI对象，而这些GUI对象只是为开发人员准备的。结果是相同的配置和部署构建。这将很容易地为每个开发人员节省每天2-3个小时的时间来观看缓慢的Maven或M2E构建，并释放配置/构建工程师在部署主机上进行更多的应用程序测试。
Getting over the mindset of write/compile/assemble/build/deploy/test is the only major impediment. Pretending you're coding on a 1979 VT100 terminal instead of a modern machine doesn't make you a 'real' developer, it just demonstrates that your methods are 35 years out of date.
克服编写/编译/组装/构建/部署/测试的思维模式是唯一的障碍。假设您是在1979年的VT100终端上编写代码，而不是在一台现代机器上编写代码，这并不意味着您是一个“真正的”开发人员，它只是表明您的方法已经过时了35年。
Of the developers on the team, none of the others properly understands a live object environment like Eclipse sufficiently to get it to work as a live environment with M2E and OSGi, and they are top developers, they just haven't been exposed to it due to the prevalence of outdated command line development tools. They only realized it was possible to do so when we were pair programming to solve the configuration problem and I was sharing my screen, causing one of the other team members to exclaim "that's how you write code so damn fast", when he saw my code change instantly test itself in the background OSGi container. I can use a bash shell when I have to, such as when I'm looking at logs on a remote server, in fact I do so fairly efficiently precisely so I can get out of that environment as quickly as possible and return to the 21st century.
开发人员的团队,没有一个人正确理解像Eclipse这样的活对象的环境足以让它工作作为生活环境M2E和OSGi,和他们是高级开发人员,他们只是没有接触它因普遍存在的过时的命令行开发工具。他们只意识到这么做当我们结对编程解决配置问题和我分享我的屏幕,导致其他团队成员之一惊叫“这就是你编写代码这么快”,当他看到我的代码变更立即测试本身在后台OSGi容器。我可以在必要的时候使用bash shell，比如当我查看远程服务器上的日志时，实际上我这样做的效率相当高，这样我就可以尽快离开这个环境，回到21世纪。
#3
5
There are soo many advantages to using Ant or Maven.
使用Ant或Maven有很多优点。
Maven is more or less an update concept of Ant. Instead of giving you a bullet point answer I have decided to take another approach into answering this question. I'll ask you a simple question. I'am assuming here that you would be a developer; or have some sort of OO programming background.
Maven或多或少是Ant的更新概念。我没有给你一个要点回答，而是决定采取另一种方法来回答这个问题。我要问你一个简单的问题。我假设你是一个开发人员;或者有一些OO编程的背景。
So If your manager was to ask you to copy two hundred directories, but ignore jar, war and ear files within those directories and once copied. You then deploy those two hundred directories to another destination but deploy only .class files; copy rest of the files into another destination etc.
因此，如果您的经理要求您复制200个目录，但是忽略jar、war和ear文件并在这些目录中进行复制。然后将这200个目录部署到另一个目的地，但只部署.class文件;将其余的文件复制到另一个目的地。
For you to do this in java; it will be lots of logic, lots of code and would not be extensible or adaptable to change. So that in mind Ant or Maven will accomplish and prepare all this on the fly with less overhead for your application to use. The size of the code in ant or Maven will be 1/4 compare to Java.
用java做这个;它将包含大量的逻辑、大量的代码，并且不能扩展或适应更改。因此，Ant或Maven将在您的应用程序使用的开销较小的情况下完成并准备所有这些工作。ant或Maven中的代码的大小将是Java的1/4。
Click on the links for more technical benefits:
点击链接获得更多的技术好处:
Maven
Ant I could not find an authentic answer with benefits, but I'm sure this would convince you ;)
我找不到可靠的答案，但我相信这能说服你;
#4
5
Maven and Ant are used to script builds so that they may be executed in batch jobs like with Jenkins or on the command line.
Maven和Ant用于脚本构建，以便它们可以像Jenkins或命令行那样在批处理作业中执行。
In fact Eclipse itself uses Ant extensively to build plugins.
事实上，Eclipse本身广泛地使用Ant来构建插件。
If you were to learn one of the two, learn Maven, it's the one pretty much everyone uses these days (replacing Ant).
如果你要学习其中的一个，学习Maven，这是当今几乎所有人都在使用的(取代Ant)。
#5
2
Maven is generally used to build the plugins or jars for a particular application.
Maven通常用于为特定的应用程序构建插件或jar。
Suppose you have developed an application but you don't want to go for adding the jars needed for that application manually. In this situation Maven or Ant is very helpful. Once you have written your code just got to Run As -> Maven Build (click on Maven Build) , it will generate all the required plugins or jars and include in your application library build-path. A doubt may come like how the application will get those jars, For each application there is a xml file named as POM.xml where reference of all the jars are kept there for downloading purposes.
假设您已经开发了一个应用程序，但您不希望手动添加该应用程序所需的jar。在这种情况下，Maven或Ant非常有用。一旦您编写了代码，并以-> Maven构建的形式运行(单击Maven构建)，它将生成所有必需的插件或jar，并在应用程序库构建路径中包含这些内容。人们可能会怀疑应用程序如何获得这些jar，因为每个应用程序都有一个名为POM的xml文件。将所有jar的引用保存在那里以便下载。