Maven全解

认识Maven之前准备一些问题：

1、 关于Maven：maven是什么？Maven能做哪些事情？Maven怎么用,
maven官方资料在哪里？Maven在哪里用，Maven和其他的项目管理工具比较的优缺点?Maven的缺点是什么，使用中有哪些弊端、存在哪些问题，有哪些还未实现、需要改进的地方？

2、 在Maven出现之前，如果我们希望在自己的程序中使用第三方类库，需要怎么做呢？

3、 Maven创建的项目是什么样子的？

4、 如何在Myeclipe和eclipse使用Maven?

下面带着问题去认识Maven

(一) Maven命名：

Maven这个单词来自于意第绪语，意为知识的积累，最早在Jakata Turbine项目中它开始被用来试图简化构建过程。

(二) Maven官方参考

首先是Maven的官网guide，包含了相当多的内容。有时间的时候应该全部浏览一遍。

http://maven.apache.org/guides/index.html

(三) 项目管理工具Maven——相关书籍来两本《Maven权威指南》《Maven实战》

(四)Maven架构图

它采用了现在流行的插件体系架构，只保留最小的核心，其余功能都通过插件的形式提供，所以 Maven 下载很小（1.1M），在执行 Maven 任务时，才会自动下载需要的插件。而且，Maven 还是跨平台的，并且提供了支持很多 Java IDE 的扩展插件。在开发中，我们大部分的时间，用到的是 Maven 的插件。

(五) Maven的设计特点

1、设计了领域模型，所有的功能围绕项目Project这个领域模型构建

2、设计了领域模型的生命周期和执行方式（lifecycle-phase-goal)

3、设计了项目的原型模式(architype）

4、设计了可扩展的插件体系(plugin-mojo)

5、设计了依赖管理(dependencies)

6、设计了动态配置机制(profile)

7、设计了artiface仓库模型(repositories）

从这7个设计点可以看出，maven这个平台设计得很清晰，对需要解决的问题（项目管理构建）设计了一系列的概念，功能，流程，方便maven的使用者明确的掌握，同时又可以针对自己的个性化需要去定制扩展平台的功能

(六) Maven能做哪些事情

Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具

(七) 使用Maven的好处

1. Maven的库是由开源组织维护，不需要我们再花精力去管第三方库，即使自己维护，也比较方便。

2. Maven对jar包的版本管理有工具上的支持，比如将Release版本和Snapshot版本区分开，有利于SCM管理。

3. Maven是标准，用过的人多，不需要额外培训。

4. Maven的plugin比较多，可以有更多功能，Maven现有体系比较开放，采用的技术相对比较通用和成熟，plugin的机制也可以便于我们扩展更多功能。

5. Maven的库下载是即用即下，不需要实现全部down下来。Maven的插件也是自动升级，可以方便的我们扩展新功能。

6. 可以很方便的与eclipse, IDEA这样的主流的IDE集成

7. 版本管理功能，这里的版本管理不是指第三方库的版本管理，而是项目的版本管理

8. 站点功能：它的出现让我们可以对项目的状态一目了然，可以自动的把项目的状态和各种报表以站点的形式发布到内部网或者外部网，可以随时随地查看项目状态。有很多中报表可以选择，包括，doc生成，代码规范的检查，自动bug检查，单元测试报表，单元测试的代码覆盖率报表。

(八) Maven的使用误区和解决方案

参考来源：http://www.54chen.com/java-ee/about-maven-10-wrong-things.html

1.频繁在所有项目使用mvn install并且随时在更新

这是我见过的最常见的问题，解决了这个问题有许多的好处。在maven的文档中找不到一句对这种情况的描述，不过我坚信一句话：每个artifact在maven仓库中都有一个家。

在你的公司里，应该有一个仓库管理工具。每一个你开发的模块都应该发布到这个仓库上去。你可能会问，应该什么时候发布？答案是，每次在你的构建服务器构建之后，都需要发到仓库。我们通常都使用Hudson来做这件事情，另外还有Continuum和TeamCity也还不错。

现在，当你所有的项目都在仓库里有的时候，你的项目就不再需要不断地mvn install了。如果你修改一个模块，你只需要重建这个模块，其余依赖的模块会由maven自动从仓库中下载。

2.你和你的团队成员依靠复制.m2文件夹来解决项目里的依赖找不到的问题

这看起来很疯狂，不过这件事情经常发生。解决的办法，设置一名仓库管理员。一旦管理好了仓库，就不会再出现大家找u盘复制.m2文件夹的事情了。因为可以加速，你不应该把本地的仓库整个地删除掉，毕竟在本地读取仓库是最快的。

3. 你为了解决依赖找不到一个老版本构件的问题，把最新的pom文件修改了版本弄到了老文件里后安装

考虑到这种情况，有人把一个模块的版本从1.3-SNAPSHOT修改成了1.4-SNAPSHOT。你马上要去度假，所以呢你就不想再更新和安装1.3的版本了，而你的模块正好要依赖1.3版本的那个模块，你如何去弄到老的版本呢？嗯，你可以到处找找，在代码库里找到了这个模块的最新代码，而且版本还是1.3的，你更新了这个版本号并且进行了安装。或者你还可以把你的代码从1.4弄到1.3去，安装并祈祷能够正常工作。

我想上面的解决办法都不是很好，同样，你的公司需要一个代码仓库管理员，如果有一次1.3-SNAPSHOT成功的构建，那就应该在仓库里存在一份，问题解决。

4. 你有许多shell脚本或者是批处理文件，它们通过你的模块的target文件来产生一个zip文件

maven有方法专门做这件事情，叫做“assemblies”。他们不是最容易安装的，但是一旦你安装好了，将与maven完全无缝结合，这要比许多山寨自制的脚本要平滑得多。这些山寨的脚本有许多的问题，比如说版本开始改变，模块被移动等等。

5.你有许多的xml在pom里，目的只是复制文件到发布时的文件夹去，而且它不成很好的工作，也不轻便

这和4正好是对立的，maven看上去不是为了复制文件而构建。如果你想复制你的包（诸如war,ear,zip文件），写一个ant shell bat文件都会很简单完成。

6.你在build的时候总是呆在“checkingfor updates from xxx-repo”而你不知道什么原因

这是一个很让有些人很气愤的事情，往往花费太多时间去找问题所在。也许这个事情正好可以让你去喝杯咖啡。尽管如此，这个问题的一些通常原因，就是你有一个快照版本的依赖，并且在你的pom文件中有一堆的仓库列表。maven不关心哪个包去哪个仓库里取，所以看上去是从所有的仓库里更新所有的包。

如果你配置了你的maven安装时到指定的仓库里去寻找所有的包（在settings.xml里设置mirror），maven会只到这个仓库里寻找。当这个服务器在本地，将得到加速。用上仓库管理很重要，

7.如果你在release分支上写代码，你的trunk的构建将会失败（或者说是1.0-SNAPSHOT应该对所有人来说都是好用的）

有许多事情你应该记住，当给你的项目创建一个分枝的时候。其中之一是告诉你的构建服务器，并且其他模块需要修改版本为你的pom的声明。如果你忽略随后才做这事，当你想修改了分支里的代码又想在主干里开发时，你会遇到问题。

这里有一个goal在发布插件里，叫做“branch”，靠运行“mvn release:branch”，maven可以为你自动重命名pom文件里的版本号。（免责声明，我还没试过这个命令。。。目前我经常只在创建了一个release的时候才打分支，在“mvn release:perform”后使用“mvn release:prepare”）

8.整个公司内容的依赖都是以-SNAPSHOT结束

快照对开发者来说很舒服，它几乎要完成了，但是迟早，你应该要停下你的脚步，发送你的包给世人，或者是你的同事。一直呆在快照版本有许多的问题。首先它减慢了你的构建速度。因为maven不得不去检查最后的快照是不是在更新了。其次，如果你的项目依赖于一个快照版本，你很难判断是依赖哪个版本的快照。构建可能会失败，只是因为你拿到了一个更新的快照。

如果你依赖一个公司内部的模块，并且这个模块目前是好用的，那么修改所有的依赖为非快照版本后才发布，是一个不错的主意。这样我们才能知道，即使有家伙还在那个模块上疯狂写代码的时候，你的模块依旧可以构建通过，因为它依赖的是一个稳定的发布。

9.跑一下“mvndependency:analyze”，没有使用和没有使用的依赖列表很长

这个很BT，但不知道准确依赖很危险。最大的问题是maven的传递依赖。

10.当有人发布了你使用的新版本的插件，你的构建就挂了

maven的插件不必写上版本，maven会找到最好的版本。当有新版本的插件的时候，你不必知道就会下载使用最新的。有时候，最好的判断不总是正确。根据经验，越新的越有bug。因此，明码标价写上你使用的插件的版本是有意义的

(九) Maven的生命周期

在 Maven2 中有了明确的生命周期概念，而且都提供与之对应的命令，使得项目构建更加清晰明了。主要的生命周期阶段：

validate，验证工程是否正确，所有需要的资源是否可用。
verify，运行任何检查，验证包是否有效且达到质量标准。
integration-test，在集成测试可以运行的环境中处理和发布包。
generate-sources，产生应用需要的任何额外的源代码，如xdoclet。
compile，编译项目的源代码。
test-compile，编译项目测试代码。
test，使用已编译的测试代码，测试已编译的源代码。
package，已发布的格式，如jar，将已编译的源代码打包。
install，把包安装在本地的repository中，可以被其他工程作为依赖来使用。
deploy，在整合或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。

关于Maven中央库的使用

(十) 在Maven出现之前，如果我们希望在自己的程序中使用第三方类库，需要怎么做呢？

首先，得到这个类库的jar包。可以从官网上下载，也可以从别的地方copy过来。

然后把这个包import到IDE中的JRE System Library中，就可以开始使用了。

(十一) Maven常用命令

mvn archetype：create 创建Maven项目

mvn compile 编译源代码

mvn deploy 发布项目

mvn test-compile 编译测试源代码

mvn test 运行应用程序中的单元测试

mvn site 生成项目相关信息的网站

mvn clean 清除项目目录中的生成结果

mvn package 根据项目生成的jar

mvn install 在本地Repository中安装jar

mvn eclipse:eclipse 生成eclipse项目文件

mvnjetty:run 启动jetty服务

mvntomcat:run 启动tomcat服务

mvn clean package -Dmaven.test.skip=true:清除以前的包后重新打包，跳过测试类

(十二) Maven自带的 "goals "有以下功能:

编译源代码

产生Javadoc文档

运行unit测试

源代码文法分析

产生违反团队编码规范的详细报告

产生CVS最新提交报告

产生CVS更改最频繁的文件报告和提交最频繁的开发人员报告

产生可以交叉引用的HTML格式的源代码，等等。

(十三) Maven手动添加jar包依赖

Maven 中是通过在 pom.xml 中添加依赖从而来引入jar 包的。其原理是：每一个 jar 都会有独立的坐标，Maven 就是通过坐标来定位到具体的 jar 的。

就好像平面坐标系一样，通过 x 轴和 y 轴定位一个坐标点。Maven 定义了这样一组规则：世界上任何一个构件都可以使用 Maven 坐标唯一标识，Maven 坐标的元素包括 groupId 、artifactId 、version 、packaging 、classifier 。只要我们提供正确的坐标元素，Maven 就能够找到它。



有的人可能会有疑问，以前没有 Maven 的时候，我们可以去各自的官网下载 jar，但现在只能通过 pom 引用 jar。那么如何知道需要添加哪些依赖呢？还有需要什么版本呢？这也是为什么有一部分习惯了自己下载 jar，而到了 Maven 这不知道该怎么用了。

当然，Maven 还不是智能的，你不可能直接命令 Maven 直接给你找项目所需要的各种组件，或许以后这样的智能化的软件管理工具会出现，至少现在还没有。因此，还得需要你自己去添加 pom 依赖。至于该如何找，这里我告诉大家一个方法，虽然方法有点笨，但或许对你快速定位到具体组件有所帮助。

举个例子，假如现在需要添加 Hibernate 的依赖，但具体哪个版本呢，可以先不用管，直接去 Baidu 或者 Google，以“ maven spring repository ”为关键字搜索，往往第一个链接中，就是你需要的方案。



进入第一链接之后，你会看到这样一个页面，搜索的结果都是关于 Spring 的，根据你的需要，选择一个链接进入，列表中有各个版本的组件，点击你需要的版本，然后就会看到 Maven 坐标。把它复制到你的 pom 文件中就噢啦。







当然，这只是一种方法，只针对刚接触 Maven 的童鞋们。随着项目经验的增多，以后你就会越来越发现，Maven 解放的不仅仅是你的双手，还有你最宝贵的时间。