我有一个Java辅助项目。这是一个非常简单的webapp。它在Linux服务器上的Tomcat中运行，并使用MySQL数据库。大部分代码是用Spring框架编写的。它有很多单元测试。当我编写代码时，它是在Eclipse中。部署应用程序时，我运行一些Shell脚本以将WAR文件移动到Web服务器，进行数据库更新，并对Apache配置进行更改。我是唯一从事此工作的开发人员，目前它仅部署到1个环境(生产环境)，尽管有一天我可能还希望拥有一个测试或者临时环境。我通过Eclipse插件使用SVN版本控制。

我经常听到有人在项目中使用Maven。既然有这么多人在使用它，我对自己说的一定很好。我想在业余时间学习它。唯一的事情是我为什么要使用Maven的机会还不够。我的第一段听起来像是适合Maven的项目吗？对于与数据库交互的项目是否有任何特定的优势？

解决方案

我在生气时正在使用Maven。这是一个苛刻的情妇。只要我们正在做许多其他人拥有的事情，这就会使事情变得容易，并且，这很重要，只要我们按照maven认为自己应该做的方式来做。走出那条狭窄的道路，它将与我们抗衡。

BuildR在侧面使用它给我留下了深刻的印象。在利用maven的依赖系统时，它像ANT一样灵活。另外，它还在孵化中，因此边缘有些粗糙。

我们完全按照我们在项目中所做的工作，并且使用maven。我们希望使用maven来具有标准化的布局和构建项目的方式。我们不必将所有这些jar依赖项存储在SVN中或者将它们保留在特殊的地方，maven会为我们完成。 Maven也是一种使其他开发人员轻松理解项目的方式。一旦开始使用它，我们将永远不会回头:)

Maven非常适合项目IMO。 Maven是一个全面的构建和部署管理工具。它的最大优势是，与功能可比的Ant文件或者Shell脚本相比，它使构建脚本更易于维护。

使用Maven的最大好处是约定优于配置。这意味着，如果使用Maven目录结构对项目进行布局，则几乎不需要进行配置即可构建和运行JUnit测试。

Maven给我们带来的另一个大胜利是依赖管理。我们可以在称为项目对象模型(POM)的Maven的配置文件中声明性地定义项目的依赖项，然后Maven会将所有jar保存在它维护的本地目录结构中。对于可公开获得的工件，罐子是从Maven中央存储库中自动下载的；对于内部或者专有的第三方罐子，则可以使用单个命令将其安装到存储库中。

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

另外，从专业开发的角度来看，学习Maven是有意义的，因为根据我的经验，Maven已超越Ant，成为开源和专有Java项目中法律上首选的构建工具。

综上所述，如果我们拥有一个快速，可靠的构建系统，那么仅仅为了使用与其他人相同的工具而转换到Maven可能不值得。

Maven可以满足需求。与大多数构建工具不同，maven明智地使用了约定(至少比许多其他约定要好)，并且在我们提到的每个区域都有"插件"：

单元测试：Maven surefire插件

Eclipse集成：m2eclipse

部署WAR文件：WAR插件和Deploy插件

Maven还可以在Tomcat上进行集成测试(如果有的话)，因为我们可以使用cargo插件启动，停止或者部署战争。

无论如何，如果我们打算在业余时间阅读，这是一本免费的书(PDF格式)：Maven权威指南

希望能帮助到你！

项目听起来不像是适合Maven的项目。我们似乎有一个正常的开发环境。为什么还要设置另一个？它只会给我们提供一个要维护的项目文件，这违反了良好的DRY原则。

除了许多oss项目正在使用(或者转换为)maven以及一些封闭源项目正在迁移到maven的事实之外，使用Maven并不一定会使项目受益良多。

但是，如果我们考虑开放源代码，则项目的用户可能会从使用maven的项目中受益。

使用ivy(http://ant.apache.org/ivy/)可以获得Maven(jar依赖)的一些重要好处。

再说一次，因为我们似乎表明自己是唯一的开发人员。如果maven不适用于我们，则可以快速恢复。

BR
〜A

别。看看别人在说什么，并仔细研究。也可以考虑在SO上查看我对Maven的其他一些评论。

前一段时间，我使用maven进行依赖管理，因为如果我想在另一个盒子上测试它，我就厌倦了添加所有jar。我们实际上不必为此"学习"，直到学习它就不需要花费很多时间。

但是，最简单的方法是问一个已经知道mvn的人，这样他就可以向我们展示它的工作原理，然后我们可以很快地学习它。

我曾经开始使用Maven进行新的临时工作。花费了2天的时间试图弄清楚他们的Maven构建是如何工作的。原来他们都在Windows上使用maven 1.01，而我一直在无意中尝试在1.02上进行构建，因此它对我不起作用。没有人知道它是如何工作的，他们已经使用了几个月，他们对此感到满意。几个月后，在同一个项目中，我不得不深入研究果冻脚本以更改单个构建变量。不好玩。

首次开始使用它时，我会读"配置之上的约定"和"使用一组标准目录"。这些不是我在文档中可以找到的任何地方。我猜你应该猜。

我的意见：

• 我们使用的任何我们不完全理解的工具都是一个错误，并且可能成为我们开发过程的潜在锚点。如果该工具确实非常复杂，则我们有责任使用其中最简单的部分，而不用深入掌握它。如果我们不使用或者避开该工具最强大的部分，则可能会违反使用该工具的目的。
• Maven是一个充满自动魔术性优点的经典示例，除非我们花了比构建工具值得成为Maven Maven多得多的时间，否则我们根本不知道它在做什么。寻找问题的过度设计的解决方案。
• 我没有发现需要做的事情的任何实例，这些事情是我无法使用蚂蚁完成的，并且需要Maven来完成。我知道有一些，我只是从来不需要它们。如果我做到了，我可能会更加善于对待行家所需的努力。
• 它使构建依赖于Internet。现在下载一个小项目，运行mvn，并让maven下载10个插件，然后甚至开始构建我们首先要构建的内容，这并不少见。到底在做什么没办法知道，但我们最好希望它不会崩溃。当它确实发生故障时，故障的复杂性和依存关系的堆积层使调试几乎毫无希望。我看不到为什么这无论是对简单构建工具的改进，还是出于任何原因甚至是可取的。

总而言之，这几乎是魔术，只是当它不起作用时，我们可能不知道为什么。这似乎是一个不好的权衡。公平地说，这是几年前的事。我知道我很不友善，并且在后续版本中也有所改进(我也使用过)。尽管如此，我还是讨厌(你能告诉我吗？)

Maven的一项强项就是无需编写任何构建脚本甚至无需描述构建过程，它就可以执行大量的构建/依赖管理。我们已经具有项目设置，因此我们不必从Maven为我们设置项目Shell或者下载指定的依赖项中受益，而不必单独下载它们。如果目标是学习如何使用和管理Maven，那么对于这样一个没有其他开发人员并且构建过程非常简单的项目(据我所知)也不会有太大帮助。因此，我建议不要在现有项目中使用Maven。

但是，我将使用Maven设置一个与应用程序类似的简单测试应用程序，并将其与项目的结构进行比较，以查看我们是否遵循最佳实践(至少在Maven开发人员看来是这样)以及应用程序是否遵循标准的Web应用程序约定。