学习Maven的思考

Question

我有一个侧面项目我在Java中。这是一个非常简单的webapp。它在Linux服务器上运行Tomcat并使用MySQL数据库。大多数代码都是使用Spring Framework编写的。它有很多单元测试。当我在Eclipse中编码时。当我部署应用程序时，我运行一些shell脚本将WAR文件移动到Web服务器，执行数据库更新，并对apache配置进行更改。我是唯一一个开发它的开发人员，现在它只部署到一个环境（生产），虽然有一天我可能想要一个测试或暂存环境。我通过Eclipse插件使用SVN版本控制。

我总是听说有人使用Maven作为他们的项目。由于有这么多人使用它，我对自己说它一定很好。我想在业余时间学习它。唯一的问题是我为什么要使用Maven并不是很畅销？我的第一段听起来像是适合Maven的项目吗？对于与数据库交互的项目，它是否具有任何特定优势？

Answer 1

Maven非常适合您的项目IMO。 Maven是一个全面的构建和部署管理工具。它最大的优势在于它使构建脚本能够比功能相当的Ant文件或shell脚本显着地维护。

使用maven有很多优点，其中最大的优点是约定优于配置。这意味着如果您使用Maven目录结构布置项目，则几乎不需要任何配置来构建和运行JUnit测试。

Maven给你的另一个重大胜利是依赖管理。您可以在Maven的配置文件（称为项目对象模型（POM））中以声明方式定义项目的依赖项，Maven可以将所有jar存储在它维护的本地目录结构中。对于公开可用的工件，罐子会自动从Maven中央存储库下载，如果是内部或专有的第三方罐子，您可以使用一个命令将它们安装到存储库中。

除了组织这些工件并自动设置构建类路径以包含所有必需的jar之外，maven还将管理依赖层次结构。这意味着如果你的项目依赖于jar A而A依赖于jar B，那么即使你没有在构建配置中明确地将它列为依赖项，jar B也会自动与你的WAR捆绑在一起。

另外，从专业开发的角度来看，学习Maven是有道理的，因为根据我的经验，Maven已经取代Ant作为开源和专有Java项目中的法律选择构建工具。

所有这一切，如果你有一个快速可靠的构建系统，那么仅仅为了使用其他人使用相同的工具而转换为Maven可能是不值得的。

Answer 2

Maven对你想做的事情很好。与大多数构建工具不同，maven明智地使用约定（至少比其他许多工具更好），并且它为您提到的每个区域都有“插件”：

单元测试：maven surefire plugin

Eclipse集成：m2eclipse

部署WAR文件：WAR plugin和Deploy plugin

Maven还可以帮助您对Tomcat进行集成测试（如果有的话），因为您可以使用cargo plugin启动，停止或部署战争。

无论如何，如果你打算在业余时间阅读，这里有一本免费的书（PDF格式）：Maven the definitive guide

希望它有所帮助！

Answer 3

我在工作中愤怒地使用maven。这是一个严厉的情妇。只要你正在做很多其他人所拥有的事情，这会让事情变得简单，这很重要，只要你按照maven认为应该做的方式来做。走开那条狭窄的道路，它会在每一步都为你而战。

我BuildR从侧面使用它给我留下了深刻的印象。它可以像ANT一样灵活，同时利用maven的依赖系统。此外，它正处于孵化阶段，所以它的边缘有点粗糙。

Answer 4

您的项目听起来不像是适合Maven的项目。您似乎有一个有效的开发环境。为什么要设置另一个？它只会给你一个项目文件来维护，这打破了良好的'DRY原则。

Answer 5

我曾经开始使用Maven的新临时工作。烧了2天试图找出他们的maven构建是如何工作的。原来他们都在窗户上使用maven 1.01，而且我无意中试图在1.02上构建，所以它对我不起作用。没有人在新的地方如何运作，他们已经使用了几个月，他们很高兴。几个月后，在同一个项目中，我不得不深入研究果冻脚本以更改单个构建变量。这不好玩。

当我第一次开始使用它时，我读到“约定优于配置”，并且“使用一组标准目录”。这些都不是我在文档中找到的任何地方。我想你应该猜测。

我的意见：

• 您使用的任何您不完全理解的工具都是错误的，并且是您开发过程的潜在锚点。如果该工具真的非常复杂，那么您可能会使用它的最简单部分而不是深入掌握它。如果你没有使用或回避工具中最强大的部分，你很可能会失去使用它的目的。
• Maven是一个充满自动化善的东西的典型例子，你不知道它在做什么，除非你投入的时间远远超过构建工具应该成为一个maven maven。寻找问题的过度设计解决方案。
• 我没有找到任何我需要做的事情，我不能用蚂蚁和需要maven。我知道有一些，我从来不需要它们。如果我这样做，我可能会对处理maven所需的努力更加慈善。
• 它使您的构建依赖于互联网。现在下载一个小项目，运行mvn并让maven下载10个插件，甚至在它开始构建你想要构建的东西之前，这并不罕见。它在做什么？没办法真的知道，但你最好希望它不会破裂。当它失败时，失败的复杂性和依赖性的堆积层使得它基本上无望调试。我不明白为什么这对于更简单的构建工具有任何改进，甚至出于任何原因都是可取的。

总之，它几乎是魔术，除了当它不起作用时你可能不知道为什么。这似乎是一个糟糕的权衡。几年前，这是公平的。我知道我是不仁慈的，并且在后续版本中也得到了改进（我也使用过它）。不过，我讨厌它（你能说出来吗？）

Answer 6

我们完全按照您在项目中所做的，我们使用maven。您希望使用maven来实现标准化布局和构建项目的方法。您永远不必将所有这些jar依赖项存储在SVN中或将它们保存在特殊区域，maven会为您执行此操作。 Maven还可以让其他开发人员轻松了解您的项目。一旦你开始使用它，你永远不想回头看:)）

Answer 7

除了许多oss项目正在使用（或转换为）maven并且一些封闭源项目正在转向maven这一事实之外，您的项目并不一定会因使用Maven而受益匪浅。

但是，如果您考虑开源，那么项目的用户可能会从您的maven项目中受益。

maven（jar依赖项）的一些重要好处可以用于常春藤（http://ant.apache.org/ivy/）。

然后，再次，因为您似乎表明您是唯一的开发人员。如果maven对你不起作用，你可以迅速恢复。

BR，
〜A

Answer 8

别。看看其他人saying，并仔细研究。另外考虑在SO上查看我对Maven的一些其他评论。

Answer 9

前段时间我使用maven进行依赖管理，因为我厌倦了添加所有的jar，如果我想在另一个盒子上测试它的话。你不必为此“学习”它，直到你学习它并不需要花费太多时间。

然而最简单的事情就是问一个已经认识mvn的人，这样他就可以告诉你它是如何工作的，然后你就会很快学会它。

Answer 10

Maven的一大优势在于，它可以在不编写任何构建脚本或甚至不必描述构建过程的情况下执行大量构建/依赖管理。您已经拥有了项目设置，因此您无法从Maven为您设置项目shell或下载您指定的依赖项而无需单独下载它们。如果您的目标是学习如何使用和管理Maven，那么这样做的项目就是这样，没有其他开发人员，而且构建过程非常简单（从我能说的）也不会有太大帮助。所以我建议不要在现有项目中使用Maven。

然而，我会使用Maven设置一个类似于您的简单测试应用程序，并将其与您项目的结构进行比较，看看您是否遵循最佳实践（至少在Maven开发人员看到它们时）以及您的应用程序是否遵循标准Web应用程序约定。