2016-01-5 16:13:43
发现一些错误，文章修改中……
（部分图片截取自其他地方，不是很清楚）
一、 maven的项目创建和基本命令
maven是一个项目管理工具，包含了一个项目对象模型POM，一组标准集合，一个项目生命周期，一个依赖管理系统，和用来运行定义在生命周期阶段中插件目标的逻辑。
maven遵循约定由于配置的原则，是指maven虽然支持配置方式，但如果有约定好的默认值，比如约定好的目录结构，就使用约定的。
maven的安装不再介绍，验证maven是否安装成功：
安装成功后，maven下有四个目录：
bin:包含运行命令mvn、mvnDebug等，既有在windows下运行的，也有在linux/unix下运行的；
boot:有maven自己开发的类加载器;
lib：maven运行所需要的一些jar包，刚安装maven时，它其实是非常小的，它只安装了自己必须的jar包。对于以后在工作中所需要的插件、jar包，他会根据你的需要不断的进行下载。
conf:配置文件setting.xml，如果在里面改变配置参数的话，它会对所有的系统用户都生效，但我们通常并不希望这件事情发生，我们希望配置只对当前用户生效，所以通常会把settings.xml粘贴到到c盘的.m2下。
具体的项目创建：
博客http://blog.csdn.net/edward0830ly/article/details/8748986中介绍的很清楚
常用的命令：
mvn compile ：会对src/main目录底下的资源和类进行编译处理，src/main/resources目录中的所有文件及子目录，会复制到target/classes目录中，为以后的打包提供了方便。
mvn test-compile ：只对测试目录底下的类和资源进行处理，但因为测试依赖于main下面的资源和类，所以会先对这些进行处理。src/test/resources目录中的所有文件及子目录，会复制到target/test-classes目录中，为后续的测试做准备。
mvn test ： 执行测试的一个命令，默认情况是把工程所有的testcase都执行一遍。如果需要执行某一个 testcase类，可以通过-Dtest参数。
mvn clean ：把target目录给清理掉了，很多缓存输出在target文件夹中。
（mvn claen instal l可以避免一些错误的发生，如果不执行clean，而直接install的话，其过程中生成的如.class文件就会覆盖原来的文件，这在一般情况下是没有问题的。但是，比如你在源文件删除了一个java，结果没有clean，则它依然存在与target中，可能会对最终的结果造成影响。）
mvn package ：在target目录下打包；
mvn exec：可以执行项目中的main函数。
（二）maven的生命周期
http://juvenshun.iteye.com/blog/213959
Maven有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，初学者容易将Maven的生命周期看成一个整体，其实不然。这三套生命周期分别是：
Clean Lifecycle 在进行真正的构建之前进行一些清理工作；
Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等;
Site Lifecycle 生成项目报告，站点，发布站点。
我再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成，mvn clean ，这个clean是Clean生命周期的一个阶段。Clean生命周期一共包含了三个阶段：
pre-clean 执行一些需要在clean之前完成的工作；
clean 移除所有上一次构建生成的文件；
post-clean 执行一些需要在clean之后立刻完成的工作。
注意：
在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean 等同于 mvn pre-clean clean ，如果我们运行 mvn post-clean ，那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。
Site生命周期的各个阶段：
- pre-site 执行一些需要在生成站点文档之前完成的工作
- site 生成项目的站点文档
- post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
- site-deploy 将生成的站点文档部署到特定的服务器上
对于Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，只解释一些比较重要和常用的阶段：
- process-resources 复制并处理资源文件，至target目标目录，准备打包。
- compile 编译项目的源代码。
- process-test-resources 复制并处理资源文件，至target目标测试目录。
- test-compile 编译测试源代码。
- test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
- package 接受编译好的代码，打包成可发布的格式，如 JAR 。
- install 将包安装至本地仓库，以让其它项目依赖。
- deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。
（三）POM （project object model）
Pom其实就是一个xml文件，写在节点<project></project>里面
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.test.maven</groupId> <artifactId>test1</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>test1</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>
其中，modelVersion：maven的默认版本
groupId：创建组织的标识符，一般是域名的倒写
artifactId：定义了项目在所属组织下的唯一标识，一个组织下可以有多个项目
version：当前项目的版本，SNAPSHOT，表示是快照版本，在开发中
url：这个项目所在的网页地址
properties：指定这个工程在创建或编译的时候所使用的编码格式
dependencies：这里添加了对junit的依赖
scope：确定junit在什么范围内生效。
complie:默认使用该依赖，对编译、测试、运行三种classpath都有效；
test：只对测试时有效，如这里的junit;
provided：在运行时无效，对编译和测试有效，如servlet-api;
runtime：如jdbc，对测试和运行有效，在编译时无效。
除了在上述pom.xml中配置依赖，使需要的jar包加载到本地仓库中，还可以手动加载，使用前面提过的mvn install命令，下面的例子可以参考
（四）在Eclipse中的应用
将上述POM文件中提到的test1导入到eclipse里：
首先执行命令mvn eclipse:eclipse ，生成 Eclipse 项目文件。将test1转成一个eclipse工程后，我们会发现test1里多了两个文件，一个是.classpath文件，一个是.project文件；
然后在eclipse中导入项目，file—import—exsiting……。
成功将test1导入eclipse后，如果想在这个工程中继续添加对其他的包的依赖，直接打开pom.xml文件进行编辑即可。但如果想删除某一依赖的话，因为在做mvn eclipse:eclipse时都已经添加到classpath中去了，需要在修改pom.xml文件后，再在eclipse中刷新一下，这样工程对包的依赖就改变了。
mvn eclipse:clean 删除增加的.classspath和.project文件，即清除掉eclipse的一些系统设置。
如果开发工具是intelliJ，使用mvn idea:idea，将工程改造成intellij工程。同样的可以使用 mvn idea:clean 来把这个intelliJ工程的信息给删除掉。
（五）maven本地仓库转移
本地仓库repository放在c盘其实是不太好的，因为如果要重新安装操作系统的话，仓库就会被格式化掉。
完成仓库的转移：
1、拷贝repository到其他盘下，如D盘;
2、打开.m2下的setting.xml文件（从maven的conf目录下拷贝过去的），找到
<!-- localRepository | The path to the local repository maven will use to store artifacts. | | Default: ${user.home}/.m2/repository <localRepository>/path/to/local/repo</localRepository> -->
删除注释，改为<localRepository>D: epository</localRepository>
（六）maven插件
在eclipse上安装maven插件，windows—preference-maven-installation中默认的maven是embedded的，
如果想使用本地maven的话，需要add添加进来。还要注意user settings的文件 ，这里使用的是.m2目录下的settings.xml。
在修改setting后，一定要update setting，并reindex，否则eclipse无法知道对maven的更改，这样在eclipse中使用maven插件会出问题的。
在pom中，可能会有提示功能，例如输入一个尖括号<，会自动出现可以匹配的文本，这是。因为maven插件安装时在xml catalog中加载进了maven 的xml catalog ，如下
（七）超级pom
如果工程需要对spring-beans这个包添加依赖，但本地仓库中没有这个jar包，我们执行编译等命令时可能并没有错误，因为它自动从一个位置下载下来了。
Maven怎么知道从哪下载jar包呢，因为maven有一个超级pom，这个pom是所有pom的父pom。
找到maven的安装目录，在lib底下有这么一个jar包
打开这个包，可以看到pom-4.0.0.xml
在这个文件里就规定了默认仓库的位置的，规定了java工程的目录结构，规定了plugin核心插件的版本（因为要保证maven3.3正常运行，就要保证这些插件的版本和它是匹配的）等等。
最后生效的超级pom和自定义pom叠加产生的有效的pom，即effctive pom，它的内容比我们自定义的pom多的多。
执行命令mvn help:effective-pom可以在命令行中查看effective pom，也可以很方便的在eclipse中查看，下面以hello-world工程为例进行展示：
里面有repositories和PluginRepositories，你还可以在pom中添加自己的repository，将它放在中央仓库的上面。
下面是build构建，这是maven最核心的部分了，
其中包括源代码的目录，测试源代码的目录，输出目录、资源文件的目录等，我们的工程结构就是来自于这个地方。
如何将一个已有的项目（其工程结构并不符合maven工程要求）纳入到maven管理中去呢？显然，移动相应的类、包使他符合maven工程的结构并不现实，一个有效的方法就是自定义pom文件。
再下面是<PluginManagement>，PluginManagement表示插件声明，即你在项目中的PluginManagement下声明了插件，maven不会加载该插件，pluginManagement声明可以被继承。
一个使用案例是当有父子项目的时候，父项目中可以利用PluginManagement声明子项目中需要用到的插件。之后，当子项目需要加载该插件的时候，就可以在子项目中plugins节点只配置 groupId 和 artifactId就可以完成插件的引用。
pluginManagement主要是为了统一管理插件，确保所有子项目使用的插件版本保持一致，类似的还是dependencies和dependencyManagement。
……
<plugins>中的plugin是给当前工程用的，是当前工程即将要使用到的plugin，会告诉你使用的是哪一个plugin，版本是多少以及要执行的阶段、目标。
