如果我们已经拥有Eclipse,为什么我们需要Maven或Ant?

时间:2012-05-26 07:51:35

标签: java maven ant

我认为这个问题是Compare to the IDE for Java,do we still need Ant?

的扩展

上面的问题有答案,但我想知道在Eclipse上使用Maven或Ant的具体示例。

当我在Eclipse中开发时,Eclipse会为我做所有事情,我只需要单击运行按钮。此外,Eclipse可以让您将代码导出到可运行的jar甚至是.exe for windows。

所以我真的不知道为什么我需要Maven或Ant。

如果我确实需要,我应该选择哪一个,Maven还是Ant?

5 个答案:

答案 0 :(得分:83)

  1. 因为您的同事可能更喜欢NetBeans或IDEA
  2. 因为设置可能因eclipse安装而异 -
  3. 因为您可能希望自动获取依赖项
  4. 因为你想自动完成整个构建:build,jar,应用静态代码分析,运行单元测试,生成文档,复制到某个目录,根据环境调整一些属性等。
  5. 因为一旦它自动化,您就可以使用一个持续集成系统,在每次更改或每小时构建应用程序,以确保所有内容仍然构建并且测试仍然通过...
  6. 因为Maven使用约定优于配置。
  7. 因为您的IDE可能不支持您需要的一些奇特的代码生成/转换。
  8. 因为构建脚本记录了构建过程。
  9. Eclipse是一个开发环境。但它不是构建工具。

    我个人讨厌Maven,但是YMMV。有很多选择:gradle,buildr等。

答案 1 :(得分:11)

Maven让我感到震惊,因为他们认为autoconf是领先的代码自动化并且不了解目标代码要求对象环境以任何方式有效地进行开发或部署。 Ant很糟糕,但Maven结合了Ant和Ivy的所有最糟糕的功能。它不会创建一个对象环境,并且它不能很好地使用工具。

简单地说,对象环境应该包含所有类对象,即确定系统可用对象类型的对象,它们始终是可用的和可用的。从那里我可以做任何我想做的事,实例化一个类的多个对象,设置各种序列和实例化规则等等。由于环境应该完全是实时的,我不应该需要一个构建工具。在部署我的应用程序方面,环境简单地抛出构成我的应用程序的命名空间中的代码从未引用过的所有类对象并不困难。 JVM中的垃圾收集器今天在运行中几乎完全相同。那时我有一个由我的对象和我的对象引用的所有对象(主要是类对象)组成的部署环境,即我的应用程序和所有依赖项。这就是虚拟机的工作方式。 (我们的虚拟机编写得很糟糕,我们需要在另一台Linux虚拟机上的VMWare VM上的Linux虚拟机上运行Spring VM,这是软件开发的另一个例子)。当依赖关系得到更新时,它足够简单,环境可以提示开发人员将旧代码合并到新库中,使用新库将代码合并到旧版本,或保留两个版本。提示鼓励开发人员进行稍微修改,有时需要避免每个库有20个版本,而像Maven这样的工具隐藏了这样一个事实:你有20个版本并导致Java应用程序中常见的大量运行时膨胀。

在Java开发领域,Eclipse最接近于成为一个合适的对象环境,尽管有许多插件可以通过各种方式打破范式。使用Maven时,大多数原因在严格审查时都会崩溃。

Netbeans和Idea是夸张的文本编辑器,而不是对象环境,但是如果你想将他们的工具用于数千个Eclipse插件未涵盖的东西,那么两者都可以导入和维护Eclipse项目,那么你的构建将会非常缓慢与使用Eclipse的开发人员相比,但是,如果他们纯粹是Netbeans或Idea项目,他们会很慢。

使用Maven不是一个严重的理由。

在Eclipse中导出/导入设置的简易性(在任何情况下,每个团队应该在任何IDE中执行的操作)使得不同的设置问题仅仅是开发团队的懒惰(或者空格与制表符之间的宗教争论) ,哈哈)。

同样,不是使用Maven的严重理由。

团队环境?向我展示一个尚未使用GIT或SVN等存储库的团队。为什么我们还需要通过设置Nexus repos来复制功能和维护问题?

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

运行服务器构建?现在,不应该通过实际签入到源代码的代码而不是偶然的构建将其推送到Nexus,这是个好主意吗?这对Git提出了一个观点,尤其是Git和Maven。因为在Git中我不在一个分支上工作,在本地测试,然后提交(部分是因为我的本地测试没有证明服务器构建是由于Jenkins和Eclipse中Maven配置的差异而工作)我必须将我的更改提交到另一个分支,以便查看服务器Maven构建失败,然后提交进一步更改以解决问题,从而导致repo中的源历史记录不可读。检查代码应该至少构建和传递单元测试,如果Git和Maven不在图片中应该得到保证。

如果您实际查看它,从Eclipse导出无头构建是微不足道的 - 您只需要ant或Gradle,已经由Eclipse维护的开发人员构建,以及一些Eclipse jar(Eclipse将为无头导出所有必需的文件)构建到目录或zip文件,或将它们ftp到构建服务器)。像Hudson / Jenkins这样的服务器构建工具可以从大多数源代码库中提取更新的代码并调用任何构建脚本,因此不依赖于Maven。使用Maven,您要么强迫开发人员使用不适合任何人的工具,而是建造工程师(构建工程所需的时间越长,即使使用M2E,也足以完成这种情况),或者您可能会生成服务器构建的可能性没有像工作站构建那样完全,如果你经历了使用大量M2E插件集成两者的所有麻烦,那么仍然是真的。无论哪种方式,您都会获得更慢,更脆弱的工作站构建,以便同样缓慢且更脆弱的服务器构建。在我开展的每个Maven项目中,我已经看到了在Eclipse中不会出现的瞬态Hudson / Jenkins错误,除非你已经安装了每个可能的M2E插件并且配置正确,大多数开发人员都没有。

似乎是避免Maven的另一个重要原因。

这并没有涵盖Maven的一些更基本的问题,例如它的命名空间破坏Java命名空间和XML命名空间,它的构建单元(POM)与实际部署中的任何内容都没有关系环境(考虑一下,当你通过POM分离你在成品中实际完成了什么?没什么。它完成的只是一种错误的感觉,你把关注点和功能分成了所有运行的不同构建单元作为一个单片代码);手动维护复杂配置文件的麻烦,只有当您碰巧需要使用OSGi或其他容器并且必须维护影响Maven配置且受Maven配置影响的其他配置文件时才会变得更糟;尝试运行单元测试而没有完整的代码执行环境所导致的问题;无数版本不仅包括依赖项,而且还包括Maven特定的插件(我实际上在Maven构建中看到了JAR地狱本身,其中多个Maven插件使用冲突的依赖项 - Maven应该是其中一个问题解决

是的,你可以使用Maven构建目标代码。你可以也用C或甚至汇编程序编写纯对象代码,但我不知道你为什么要这样做。

避免使用Maven的最佳理由是,当您厌倦了上述所有问题(以及许多其他未提及的问题)时,需要对一组项目进行去除大量工作。

继承自C开发的思维方式,开发周期包括编写代码,编译,汇编,构建,部署,测试,重做,在对象环境中无可救药地过时。在某些时候,我们需要告诉所有具有这种心态的人,他们需要重新学习如何发展,期间。这样做可以消除对Maven,Git和许多其他工具的需求,这些工具除了浪费时间外什么都不做。

对象开发应该在实时对象环境中完成,其中代码更改在保存时进行测试,因为修改后的对象是实时的。部署应包括从该环境中删除仅开发人工制品,创建一个运行时,其中包含正在运行的应用程序在开发和测试中使用的所有内容。

我目前正在处理因使用maven-assembly插件为OSGi应用创建部署程序集而导致的问题。该应用程序在Eclipse环境中运行良好,它将所有代码更改部署到环境中正在运行的OSGi容器中。然而,尽管有一个非常好的配置/构建工程师,其唯一的工作是完成该过程,但配置并不能通过maven-assembly过程完整地生存。如果我们摆脱了Maven(现在由于代码量很大,但可能非常困难)并且使用了BNDTOOLS Eclipse插件,我们可以简单地将Eclipse构建导出为Ant或Gradle无头构建(注意,编写BND的OSGi开发人员和BNDTOOLS 支持Maven,并且有充分的理由,Maven插件由Felix开发人员编写,他们自己使用Netbeans和Maven,除了在部署周期结束时没有实时环境),其中两个工具都设置了与Eclipse相同的相同的环境,而没有仅为开发人员设计的GUI对象。结果将是相同的配置和部署构建。对于目前用于观看慢速Maven或M2E构建的开发人员,每天可以轻松节省2-3小时,并释放配置/构建工程师以在部署主机上对应用程序进行更多测试。

克服写/编译/汇编/构建/部署/测试的思维是唯一的主要障碍。假装你在1979年的VT100终端而不是现代机器上进行编码并不能让你成为一个真实的机器。开发人员,它只是证明你的方法已经过时了35年。

在团队中的开发人员中,其他人都没有充分理解像Eclipse这样的实时对象环境,足以使其成为M2E和OSGi的实时环境,他们是顶级开发人员,他们只是没有由于过时的命令行开发工具的普遍存在而暴露于它。当我们进行结对编程以解决配置问题并且我正在共享我的屏幕时,他们才意识到可能这样做,导致其他团队成员之一惊呼" #39; s 你如何快速编写代码",当他看到我的代码更改后立即在后台OSGi容器中测试自己。我必须使用bash shell,例如当我查看远程服务器上的日志时,事实上我确实这样做非常有效,所以我可以尽快离开那个环境并返回21世纪。

答案 2 :(得分:6)

使用Ant或Maven有很多优点。

Maven或多或少是Ant的更新概念。 我决定采用另一种方法回答这个问题,而不是给你一个子弹点答案。我会问你一个简单的问题。我假设你是一名开发人员;或者有某种OO编程背景。

因此,如果您的经理要求您复制200个目录,但忽略这些目录中的jar, war and ear个文件并复制一次。然后,将这200个目录部署到另一个目标,但只部署.class个文件;将其余文件复制到另一个目的地等。

你要在java中这样做;它将是许多逻辑,大量代码,不可扩展或适应变化。因此,考虑到Ant或Maven将在运行中完成并准备所有这些,并且您的应用程序可以使用更少的开销。与Java相比,ant或Maven中的代码大小为1/4

点击链接获取更多技术优势:

Maven

Ant我无法找到有益的真实答案,但我相信这会说服你;)

答案 3 :(得分:5)

Maven和Ant用于编译脚本,以便它们可以像Jenkins一样在批处理作业中执行,也可以在命令行上执行。

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

如果你要学习其中的一个,学习Maven,那就是现在每个人都使用的那个(取代Ant)。

答案 4 :(得分:2)

Maven通常用于为特定应用程序构建插件或jar。

假设您已经开发了一个应用程序,但您不想手动添加该应用程序所需的jar。在这种情况下,Maven或Ant非常有帮助。一旦你编写了你的​​代码,就得到Run As - > Maven Build(单击Maven Build),它将生成所有必需的插件或jar,并包含在应用程序库build-path中。怀疑应用程序将如何获得这些jar,对于每个应用程序,都有一个名为POM.xml的xml文件,其中所有jar的引用都保存在那里以供下载。

相关问题