我有一个我在Java中做的项目。这是一个非常简单的web应用程序。它运行在Linux服务器上的Tomcat中，并使用MySQL数据库。大部分代码都是用Spring框架编写的。它有很多单元测试。当我编写它在Eclipse中。当我部署应用程序时，我运行几个shell脚本将WAR文件移动到Web服务器，执行数据库更新并更改apache配置。我是唯一开发它的开发人员，现在只能部署到1个环境（生产），尽管有一天我可能也想要一个测试或登台环境。我通过Eclipse插件使用SVN版本控制。思考学习Maven
我总是听说有人在项目中使用Maven。既然有这么多人在使用它，我只能说自己一定很好。我想在业余时间学习。唯一的问题是我为什么要使用Maven不太满意？我的第一段听起来像是一个适合Maven的项目吗？对于与数据库交互的项目它有什么特别的优势吗？
您的项目听起来不像适合Maven的项目。你似乎有一个有效的开发环境。为什么要建立另一个？它只会给你一个更多的项目文件来维护，这打破了好的原则。
我在工作中愤怒地使用maven。这是一个苛刻的女主人。只要你做很多其他人拥有的东西，它就让事情变得容易，只要你按照maven认为你应该做的那样做，这很重要。走出这条狭窄的道路，它会一路战斗。
我一直对BuildR留下深刻的印象。它可以像ANT一样灵活使用maven的依赖系统。此外，它在孵化，所以它的边缘有点粗糙。
我们完全按照您在我们的项目中所做的操作，并使用maven。你会想要使用maven有一个标准化的布局和方式来建立你的项目。你永远不需要将所有这些jar依赖关系存储在SVN中，或者将它们保存在特殊的地方，maven可以为你做这些。 Maven还可以帮助其他开发人员轻松理解您的项目。一旦你开始使用它，你永远不会想回头:)
Maven将会很适合你的项目IMO。 Maven是一个全能的构建和部署管理工具。最大的优势在于，它使构建脚本比维护功能相当的Ant文件或shell脚本更加易于维护。
使用maven有很多好处，最重要的是它的约定优先于配置。这意味着如果你使用Maven目录结构来布局你的项目，那么几乎不需要配置它来构建和运行你的JUnit测试。
Maven给你的另一个重大胜利是依赖管理。您可以在Maven的配置文件中声明性地定义项目的依赖项，称为项目对象模型（POM），Maven将所有的jar存储在它所维护的本地目录结构中。在公开可用的工件的情况下，罐子会自动从Maven中央存储库中下载，对于内部或专有的第三方罐子，您可以使用单个命令将它们安装到存储库中。
除了只组织这些构件并自动设置构建类路径以包含所有必需的jar之外，maven还将管理依赖关系层次结构。这意味着如果你的项目依赖于jar A，而依赖于jar B，那么jar B将自动与你的WAR捆绑在一起，即使你没有在构建配置中明确地将它列为依赖项。
此外，从专业的开发角度来看，学习Maven是有道理的，因为根据我的经验，Maven已经超越了Ant作为开源和专有Java项目中的合法构建工具。所有这些都说了，如果你有一个快速且可靠的构建系统，那么为了使用其他人所用的相同工具，将它转换为Maven可能并不值得。
Maven对于你想做的事情会很好。与大多数构建工具，Maven使用公约明智的（当然，比一般人至少更好），而且它有关于你提到的每一个领域“插件”：
Eclipse集成：m2eclipse
部署WAR文件：WAR plugin和Deploy plugin
Maven的也可以帮助你在Tomcat集成测试（如果你有一些），以后就可以开始使用cargo plugin停止或部署的战争。
无论如何，如果你打算在你的空闲时间看，这里有一个免费的电子书（PDF格式）：Maven the definitive guide
希望它能帮助！
除了一个事实，即许多OSS项目的使用（或转换为）Maven和一些封闭源代码的项目正在向Maven的时候，你的项目不一定从使用Maven受益很多。
但是，如果你会考虑开源它，那么你的项目的用户可能会受益于使用Maven的项目。
一些行家（依赖的JAR）的重要好处是可以和常春藤（http://ant.apache.org/ivy/）来了。
话又说回来，既然你似乎表明你是唯一的开发商。如果maven不适合你，你可以快速恢复。
BR，
〜一个
不要。看看还有什么其他人saying，并仔细研究。另外请考虑看看我在SO上的其他一些关于Maven的评论。
我用于依赖管理Maven的前一段时间，因为我累了将所有的罐子，如果我想测试它在另一台电脑左右。你不需要为此“学习”它，直到你学习它才花费很多时间。
但是最简单的事情是只问谁已经知道有人MVN，这样他就可以告诉你它是如何工作，然后你了解它相当快。
我曾经开始使用Maven的新临时工作。烧了2天试图找出他们的Maven构建如何工作。原来他们都是在windows上使用maven 1.01，并且我无意中试图在1.02版本上构建，所以它不适用于我。这个地方没有人知道它是如何工作的，而且他们已经使用了好几个月，他们对此感到满意。几个月后，在同一个项目中，我不得不深入研究果冻脚本来更改单个构建变量。这并不好玩。
当我第一次开始使用它时，我阅读“convention over configuration”和“使用一组标准目录”。这些都不是我能找到的文档。我想你应该猜测。
我的意见：
总之，它几乎是魔术，除非当它不起作用时，你可能不知道为什么。这似乎是一个不好的折衷。几年前这是公平的。我知道我不友好，并且在后续版本中有所改进（我也使用了这些版本）。尽管如此，我讨厌它（你能告诉吗？）
Maven的一个强大优势在于，它没有编写任何构建脚本或者甚至不必描述构建过程就可以完成很多构建/依赖管理。你已经有了你的项目设置，所以你不会从Maven为你设置项目shell或者下载你指定的依赖关系而不必单独下载它们。如果你的目标是学习如何使用和管理Maven，那么对于没有其他开发人员和构建过程的项目来说，这样做是非常简单的（从我所知道的情况来看）也无济于事。所以我建议不要在现有项目中使用Maven。
然而，我会设置一个类似于你的使用Maven的简单测试应用程序，并将其与您的项目结构进行比较，看看您是否遵循最佳实践（至少在Maven开发人员看到它们时）以及您的应用程序是否遵循标准Web应用程序约定。
Maven的主要前提是“Convention over Configuration”，这意味着他们正在为您做所有的工作，当且仅当您将自己提交给他们（通常并且容易生活）的约定范例。出于这个原因，将旧项目引入maven往往充满了灾难。 – 2009-01-02 17:03:25
@Spencer K：约定是个好主意。 maven的问题是它是近视和不灵活的。 – sblundy 2009-01-02 18:55:58