logo标签列表

如果我们已经有了Eclipse，为什么还需要Maven或Ant呢？

javamavenant
77

我认为这个问题是对与Java IDE相比，我们是否仍需要Ant的扩展。

以上问题有答案，但我希望知道使用Maven或Ant的具体示例，而不是只用Eclipse。

当我在Eclipse中开发时，Eclipse会为我完成一切工作，我只需点击运行按钮。此外，Eclipse可以让您将代码导出为可运行的jar文件，甚至是Windows的.exe文件。

因此，我真的不知道为什么需要Maven或Ant。

如果我确实需要，我应该选择Maven还是Ant？

7
你是否在团队中工作？ - Thorbjørn Ravn Andersen
23
你的公司决定每晚2点自动运行构建。你想要在那个时间赶到公司，手动点击IDE中的导出流程吗？甚至在周末也需要这样做吗？ - Donal Fellows
5
我看到很多人在使用Eclipse和Ant时都没有像Jackson那样问这个非常重要的问题。干得好，Jackson！问题是，大多数人/公司都忙于试图打败竞争对手，没有时间学习可以帮助他们节省更多时间的工具和技术。 - Nav
2
我批准这个问题...大多数开发者开始使用这些工具，甚至不想知道为什么.. - JanBo
1
那么下一个重要的问题是：我们为什么需要Eclipse？ - Lundin
@Nav，也许是因为学习所需的时间超过了学会后节省的时间。 - Pacerier
5个回答
87
  1. 因为你的同事可能更喜欢NetBeans或者IDEA。
  2. 因为不同的Eclipse安装所使用的设置可能会有所不同。
  3. 因为你可能想自动获取你的依赖项。
  4. 因为你想自动化完整的构建过程: 构建、打包jar文件、应用静态代码分析、运行单元测试、生成文档、复制到某个目录、根据环境调整一些属性等。
  5. 因为一旦自动化了，你就可以使用持续集成系统来确保每次更改或每小时都构建应用程序，以确保所有内容仍然能够构建，并且测试仍然通过......
  6. 因为Maven使用惯例优于配置。
  7. 因为你的IDE可能不支持你需要的某些高级代码生成/转换。
  8. 因为构建脚本可以记录构建过程。

Eclipse是一个开发环境，但并不是一个构建工具。

我个人讨厌Maven，但你的看法可能不同。还有其他很多替代品：gradle、buildr等等。

3
因为 Eclipse 可能不支持您所需的一些花哨代码生成/转换（因为它只能编译），所以需要考虑此问题。 - piotrek
2
Eclipse是一个开发环境。但它不是一个构建工具。不，Eclipse只是一个虚拟的构建工具 :P - yorkw
5
我是Java EE的新手，但到目前为止我已经能够使用Eclipse创建WAR并无问题地部署到远程Web服务器上。别笑我疯狂，但我喜欢保持简单，这些构建工具似乎一切都除了简单... - Dennis
1
有人需要強調第二點：2. 因為設置可能因Eclipse安裝的不同而有所不同。對於ANT，你只需學習一次。對於Eclipse，你需要每個版本都學習一次，並處理所有Eclipse以其聞名的奇怪細節和錯誤。 - Pacerier
  1. 因为Maven使用约定优于配置。这不仅对工具有用，而且对开发人员也有用，因为他们知道在哪里查找所需内容。我已经看到过在src中有多个代码目录的项目 - 其中一个是“test”。
 - Hubert Grzeskowiak
11
Maven对我来说就像是一群过气的c-shell脚本小子编写的东西，他们认为autoconf是领先的代码自动化工具，但不理解对象代码需要一个对象环境才能在开发或部署中以任何方式高效。 Ant已经糟糕到足够糟糕，但Maven结合了Ant和Ivy所有最糟糕的特征。它不会创建对象环境，也不能与共享该环境的工具良好协作。
简单点说，对象环境应该在任何时候都有所有类对象，即决定系统可用对象类型的对象。从那里，我可以做任何想做的事情，实例化某个类的多个对象，设置各种顺序和实例化规则等等。由于环境应该完全活跃，我根本不需要构建工具。对于部署我的应用程序，环境只需将所有未被命名空间中的代码引用的类对象全部删除即可。JVM中的垃圾回收器几乎可以在运行时执行同样的操作。此时，我就拥有了一个由我的对象和所有其他对象（主要是类对象）组成的部署环境，这些对象被我的对象引用，即我的应用程序和所有依赖项。这就是虚拟机的工作方式(我们的虚拟机如此糟糕，以至于我们需要在Java VM上运行Spring VM，在VMWare VM上运行另一个Linux VM中的Linux VM的又一个例子就是软件开发愚蠢的例子)。更新依赖项时，环境可以简单地提示开发人员将旧代码与新库合并、将使用新库的代码向下合并到旧版本中，或保留两个版本。提示鼓励开发人员进行微小的修改，以避免每个库的二十个版本，而像Maven这样的工具则隐藏了您拥有的二十个版本的事实，并导致Java应用程序中普遍存在的大量运行时膨胀。
在Java开发领域，Eclipse最接近正确的对象环境，尽管承认有许多插件以各种方式打破该范例。使用Maven的大部分原因在关键时刻都会崩溃。
Netbeans和Idea都是过剩的文本编辑器，不是对象环境，但如果您确实想要使用它们的工具来做一些不属于数千个Eclipse插件的事情，两者都可以导入和维护Eclipse项目，您的构建只是比使用Eclipse的开发人员慢得多，但如果他们完全使用Netbeans或Idea项目，它们也会非常慢。
这不是使用Maven的严肃理由。
在Eclipse中导出/导入设置（任何情况下都应该为每个团队所做的事情）使得不同设置问题只是开发团队的懒惰（或者是关于空格与选项卡的宗教争论，哈哈）。
同样，这并不是使用Maven的严肃理由。
团队环境？向我展示一个尚未使用类似GIT或SVN等存储库的团队。为什么我们需要通过设立Nexus repos来重复实现这两种功能和维护头疼呢？

这实际上是不使用Maven的一个很好的理由。

运行服务器构建？很好的想法，现在，应该由已经检入源代码库的代码来启动它，而不是随机推送到Nexus的构建。这引出了一个反对Git的观点，尤其是与Maven一起使用的Git。因为在Git中，我不会在分支上工作、本地测试、然后提交（部分原因是我的本地测试并不能证明服务器构建可行，因为Jenkins和Eclipse中的Maven配置存在差异），我必须将我的更改提交到另一个分支，以便看到服务器Maven构建失败，然后提交进一步的更改来解决问题，从而导致无法阅读的源历史记录在仓库中。检入的代码应该至少构建并通过单元测试，如果Git和Maven不在考虑范围内，这应该是可以保证的。

如果你真的去研究，从Eclipse导出一个headless build是微不足道的 - 你所需要的只是Ant或Gradle，它们是Eclipse开发者构建已经维护好的，还有一些Eclipse jar文件（Eclipse将所有必要的文件导出到目录或zip文件中，或者将它们通过ftp发送到构建服务器）。服务器构建工具像Hudson/Jenkins可以从大多数源代码库中拉取更新的代码，并调用任何构建脚本，没有依赖于Maven。使用Maven，你要么强制开发人员使用除了构建工程师以外任何人都不适合的工具（即使使用M2E，所需时间更长就足以证明这种情况），要么接受服务器构建不像工作站构建那样完美的可能性，即使你通过大量的M2E插件将二者集成起来，这仍然是一个事实。无论哪种方式，你都会得到一个更慢、更容易出错的工作站构建，而为此付出同样缓慢且更脆弱的服务器构建。在我所参与的每个基于Maven的项目中，我都看到了瞬态的Hudson/Jenkins错误，除非你安装并正确配置了绝对所有可能的M2E插件，否则这些错误在Eclipse中是看不到的，而大多数开发人员从未这么做。

似乎是避免Maven的另一个很好的理由。

那并不能解决Maven的一些根本性问题，例如其名称空间破坏Java名称空间和XML名称空间，构建单元（POM）与实际部署环境没有任何关系（想想看，当你通过POM进行分离时，你实际上完成了什么？什么也没完成。它只是实现了一种错误的感觉，即你已经将关注点和功能分别放入了不同的构建单元中，而所有这些构建单元都作为一个单一的代码整体运行）；手动维护复杂配置文件的麻烦程度，如果您需要使用OSGi或另一个容器并需要维护其他配置文件，则情况会变得更糟，这些配置文件会受到Maven配置的影响且会影响Maven配置，但显然没有太多明显的意义；尝试在没有完整执行代码所需环境的情况下运行单元测试所引起的问题；以及不仅依赖关系的各种版本，还有特定于Maven的插件的各种版本（我实际上在Maven构建本身中看到过JAR地狱，其中多个Maven插件正在使用冲突的依赖项 - 这是Maven应该解决的问题之一）。
是的，你可以使用Maven构建对象代码。您也可以使用C甚至汇编语言编写纯对象代码，但我不知道为什么您会想这样做。
避免Maven的最好理由是在您厌倦了上述所有问题（以及许多其他未提及的问题）时需要进行大量的去除Maven的工作。从C开发中继承而来的思维方式认为开发周期包括编写代码、编译、组装、构建、部署、测试，然而在一个对象环境中，这种思维方式已经过时了。在某个时候，我们需要告诉所有持有这种思维方式的人，他们需要重新学习如何进行开发。这样做将消除对Maven、Git和众多其他浪费时间的工具的需求。
对象开发应该在实时对象环境中完成，在这种环境中，保存修改后的对象会被测试，因为修改后的对象是活的。部署应该包括从该环境中删除仅限于开发的工件，创建一个运行时，其中包含开发和测试中运行应用程序所使用的所有内容。我目前正在处理一个问题，该问题是使用maven-assembly plugin创建部署组件导致的OSGi应用程序。该应用程序在Eclipse环境下工作完美，它可以在运行环境内的OSGi容器中热部署所有代码更改。然而，尽管有一个非常出色的配置/构建工程师专门处理这个过程，但配置在经过maven-assembly过程后却不能完整保留。如果我们摆脱Maven（由于代码量很大，现在非常困难，但是也可能实现），并使用BNDTOOLS Eclipse插件，我们可以将Eclipse构建简单地导出为Ant或Gradle headless构建（请注意，编写BND和BNDTOOLS的OSGi开发人员不支持Maven，并且有充分的理由，因为Maven插件是由Felix开发人员编写的，他们自己使用Netbeans和Maven，除了部署周期结束时没有其他实时环境），其中两种工具都设置与Eclipse相同的环境，但没有仅供开发人员使用的GUI对象。结果将是部署的相同配置和构建。这将轻松节省每个开发人员每天2-3个小时的时间，以观察缓慢的Maven或M2E构建，并释放配置/构建工程师在部署主机上进行更多的应用程序测试。
克服“编写/编译/组装/构建/部署/测试”的思维方式是唯一的主要障碍。假装你在使用1979年的VT100终端而不是现代设备并不能使你成为一个“真正”的开发人员，这只是表明你的方法已经35年过时了。
在团队中的其他开发人员中，没有人像我一样充分理解Eclipse这样的实时对象环境，并能够将其与M2E和OSGi一起作为实时环境工作，尽管他们都是顶级开发人员，但由于过时的命令行开发工具的流行，他们从未接触过这些技术。当我们进行配对编程以解决配置问题时，其中一个团队成员在看到我的代码瞬间更改并在背景OSGi容器中测试自身时，惊叹地说：“那就是你如此快速编写代码的原因”，他才意识到这是“可能”的事情。我可以使用bash shell，例如当我查看远程服务器上的日志时，事实上我可以相当高效地这样做，以便尽快摆脱这个环境并返回21世纪。
1
在前公司的一个实验中，我们取消了Maven构建，让其中一组继续使用Maven构建，另一组使用Eclipse构建。结果发现，相较于Eclipse构建，Maven构建确实可以为构建工程师每月节省约30分钟的时间。但是，这也意味着每个开发人员每天要多花费近3个小时的时间来使用Maven构建，因此代价颇高。 - Das Richardson
我们已经尝试过这些工具，它们都带来了更多的麻烦而不值得。我唯一的遗憾是我只有一个赞可以给你。 - Vincent
1
你的构建速度将会比使用Eclipse的开发者慢得多。请证明或编辑。 - Hubert Grzeskowiak
9
这个回答完全是主观看法的堆砌，没有任何参考资料或证据来支持任何论点。 - Hubert Grzeskowiak
深呼吸，数到10。好了吗？你是Eclipse开发者还是Eclipse粉丝或者什么的？ - Nathan Adams
6
使用Ant或Maven有很多优点。
Maven是对Ant的一个更新概念。我决定采用另一种方式来回答这个问题，而不是给你一个简短的答案。我会问你一个简单的问题。我假设你是一名开发人员，或者有一些面向对象编程的背景。
如果你的经理要求你复制两百个目录，但忽略这些目录中的jar、war和ear文件，并且在复制后将这两百个目录部署到另一个目的地，但只部署.class文件；将其余文件复制到另一个目标等等。
如果你要用Java来做这件事，那么就需要很多逻辑和代码，而且不能很好地扩展或适应变化。因此，Ant或Maven可以在运行时完成所有这些工作，并减少应用程序的开销。Ant或Maven的代码大小只有Java的1/4。
点击链接了解更多技术优势： Maven

蚂蚁我找不到一个真正有益的答案，但我相信这会说服你 ;)

5

Maven和Ant用于编写脚本构建，以便可以像在Jenkins中或在命令行上一样批量执行。

实际上，Eclipse本身广泛使用Ant来构建插件。

如果你要学习其中之一，那就学Maven吧，这是现在几乎每个人都在使用的（取代了Ant）。

2
Gradle非常受欢迎，现在在Android Studio中使用。 - barlop
2

Maven通常用于构建特定应用程序的插件或JAR包。

假设您已经开发了一个应用程序，但不想手动添加该应用程序所需的JAR文件。在这种情况下，Maven或Ant非常有帮助。一旦您编写好代码，只需转到“Run As -> Maven Build”（单击Maven Build），它将生成所有必需的插件或JAR文件，并包含在您的应用程序库构建路径中。可能会产生疑问，应用程序如何获取这些JAR文件？对于每个应用程序，都有一个名为POM.xml的xml文件，其中保留了所有JAR文件的引用以供下载。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接