77

我认为这个问题是对 Java IDE 的比较的扩展，我们还需要 Ant 吗？

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

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

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

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

4

5 回答 5

87
  1. 因为您的同事可能更喜欢 NetBeans 或 IDEA
  2. 因为设置可能从一个 Eclipse 安装到另一个
  3. 因为您可能希望自动获取依赖项
  4. 因为您想自动化完整的构建：构建、jar、应用静态代码分析、运行单元测试、生成文档、复制到某个目录、根据环境调整某些属性等。
  5. 因为一旦自动化，您可以使用持续集成系统在每次更改或每小时构建应用程序，以确保一切仍然构建并且测试仍然通过......
  6. 因为 Maven 使用约定优于配置。
  7. 因为您的 IDE 可能不支持您需要的一些花哨的代码生成/转换。
  8. 因为构建脚本记录了构建过程。

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

我个人讨厌 Maven，但是 YMMV。有很多选择：gradle、builder等。

于 2012-05-26T07:57:30.513 回答
11

Maven 给我的印象是一群过去销售的 c-shell 脚本小子写的东西，他们认为 autoconf 是领先的代码自动化并且不明白目标代码需要一个对象环境任何对开发或部署都有效的方式。Ant 已经够糟糕了，但 Maven 结合了 Ant 和 Ivy 的所有最糟糕的特性。它不会创建对象环境，并且不能很好地与创建对象环境配合使用。

简单地说，对象环境应该具有所有类对象，即确定系统可用的对象类型的对象，这些对象始终处于活动状态并且可用。从那里我可以做任何我想做的事，实例化一个类的多个对象，设置各种序列和实例化规则等。由于环境应该是完全实时的，我不应该需要一个构建工具。在部署我的应用程序方面，环境不难简单地丢弃构成我的应用程序的命名空间中的代码从未引用的所有类对象。今天，JVM 中的垃圾收集器在运行中几乎做同样的事情。那时我有一个由我的对象和我的对象引用的所有对象（主要是类对象）组成的部署环境，即我的应用程序和所有依赖项。这就是虚拟机的工作方式。（我们的虚拟机写得如此糟糕，我们需要在一个 Linux 虚拟机上的一个 Java 虚拟机上运行一个 Spring VM，在另一个 Linux 虚拟机上的一个 VMWare 虚拟机上运行，​​这是软件开发的另一个愚蠢的例子）。当依赖项更新时，环境会很简单地提示开发人员将他的旧代码合并到新的库中，将使用新库的代码合并到旧版本，或保留两个版本。提示鼓励开发人员进行有时必要的细微修改，以避免每个库都有 20 个版本，而 Maven 等工具隐藏了您有 20 个版本的事实，并导致 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 构建失败，然后提交进一步的更改以解决问题，导致 repo 中的源历史记录不可读。签入的代码至少应该构建并通过单元测试，如果 Git 和 Maven 不在图片范围内，则应该保证这一点。

从 Eclipse 中导出无头构建是微不足道的——您只需要 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 构建本身中看到了 JAR 地狱，其中多个 Maven 插件使用冲突的依赖项 - 这是 Maven 应该解决的问题之一。

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

避免使用 Maven 的最佳理由是，当您厌倦了上面提到的所有问题（以及许多其他未提及的问题）时，需要大量的工作来解除一组项目。

继承自 C 开发的思维模式，即开发周期包括编写代码、编译、组装、构建、部署、测试、重做，在对象环境中已经过时了。在某些时候，我们需要告诉所有有这种心态的人，他们需要重新学习如何发展，时期。这样做将消除对 Maven、Git 和许多其他只会浪费时间的工具的需求。

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

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

克服写/编译/组装/构建/部署/测试的心态是唯一的主要障碍。假装你是在 1979 年的 VT100 终端上而不是现代机器上编码并不能使你成为“真正的”开发人员，它只是表明你的方法已经过时了 35 年。

在团队中的开发人员中，没有其他人能够充分理解像 Eclipse 这样的实时对象环境，以使其能够作为具有 M2E 和 OSGi 的实时环境工作，而且他们是顶级开发人员，只是由于没有接触过它过时的命令行开发工具的流行。他们只是在我们结对编程以解决配置问题并且我正在共享我的屏幕时才意识到这样做是可能的，这导致其他团队成员中的一个惊呼“那是你怎么写代码这么快”，当他看到我的代码更改时，立即在后台 OSGi 容器中测试自己。我可以在必要时使用 bash shell，例如当我查看远程服务器上的日志时，在事实上，我这样做的效率相当高，所以我可以尽快离开那个环境，回到 21 世纪。

于 2014-07-29T09:29:13.180 回答
6

使用 Ant 或 Maven 有很多优点。

Maven 或多或少是 Ant 的更新概念。我决定采用另一种方法来回答这个问题，而不是给你一个要点答案。我会问你一个简单的问题。我在这里假设您将成为开发人员；或者有某种 OO 编程背景。

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

让您在 java 中执行此操作；它将包含大量逻辑、大量代码，并且无法扩展或适应更改。因此，请记住 Ant 或 Maven 将在运行中完成并准备所有这些，而您的应用程序使用的开销更少。ant 或 Maven 中的代码大小将1/4与 Java 进行比较。

点击链接了解更多技术优势：

马文

蚂蚁我找不到有好处的真实答案，但我相信这会让你信服；）

于 2012-05-28T16:12:58.633 回答
5

Maven 和 Ant 用于编写构建脚本，以便它们可以在批处理作业中执行，例如使用 Jenkins 或在命令行上执行。

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

如果您要学习两者之一，请学习 Maven，这是当今几乎每个人都在使用的（替代 Ant）。

于 2012-05-26T07:55:50.217 回答
2

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

假设您已经开发了一个应用程序，但您不想手动添加该应用程序所需的 jar。在这种情况下，Maven 或 Ant 非常有帮助。一旦您编写了代码，只需运行方式 -> Maven 构建（单击 Maven 构建），它将生成所有必需的插件或 jar，并包含在您的应用程序库构建路径中。可能会出现一个疑问，例如应用程序如何获取这些 jars，对于每个应用程序，都有一个名为 POM.xml 的 xml 文件，其中所有 jars 的引用都保存在那里以供下载。

于 2016-07-05T06:46:14.027 回答