Maven相关笔记

之前提到过Maven的一些东西，但并没有系统的去学习和研究。最近这段时间相对系统的学习了一下Maven这个东西，确实发现好处很多，所以在此把个人记录的一些笔记传到这里，以备不时之需。
首选，Maven的主要知识体系分为以下四大块：
1、Maven本身的安装、配置
主要就是Maven的基本设置和一些配置，属于最基本的操作，如果看过Maven实战这本电子书的话，这部分基本没什么问题。
2、Maven使用时的核心部分1——依赖
可以毫不保留的说，依赖就是Maven的核心，就类似WebProject不能没有jar一样，使用Maven，依赖是必须的。
（不是说插件不重要，不过插件只是一个辅助的作用，可以少用，甚至不用，而依赖则是每个MavenProject中必不可少的。）
3、Maven的私有仓库的使用
在这部分我主要是学习的Nexus这个Maven的私有仓库，私有仓库在团队开发时是十分重要的。
4、Maven使用时的核心部分2——插件
这部分就类似游戏中的插件一样，可以很方便的帮助你完成一些原本很繁琐的操作。

以下是个人的一些笔记：
1、Maven本身的安装、配置
1）所有的依赖都是通过坐标来进行存储的（GAV->groupId、artifactId、version）
2）有一些网站提供的坐标的查询：
http://www.mvnrepository.com/
http://search.maven.org/
2、Maven的依赖
1）通过<dependencies>设置依赖
注：maven首先会在本地仓库查询，没有的话会去中央仓库下载；
2）依赖是会被传递的
b依赖a，c依赖b，则c间接依赖a；
传递性的依赖主要是针对compile范围（默认的scope），而test范围不会传递到compile，test范围仅能传递到test范围；
3）依赖范围说明（默认为compile）
1）test：测试范围，在编译和打包时都不使用；
2）compile：编译范围，在编译和打包时都会使用；
3）provided：在编译和测试时有效，在打包时不会使用，例如servlet-api（tomcat已自带，多次打包可能带来冲突）；
4）runtime：在运行的时候使用，编译时则不使用；
4）传递依赖的冲突
1）a依赖b的1.0版本，c依赖b的1.2版本，当d同时依赖a、c；
如上情况，当d的pom.xml中先写a的依赖，则d依赖b的1.0版本，若先写c，则的依赖b的1.2版本；
2）a依赖b的1.0版本，c依赖b的1.2版本，d同时依赖a、c，并使用b的1.0版本，当e同时依赖d、c；
如上情况，当依赖路径的长短不一致时，则按照最短路径进行依赖；
3）如果希望精确的控制依赖包，可使用依赖的排除功能（加入<exclusions>即可）
5）项目的聚合
1）设置<packaging>pom</packaging>；
2）添加<modules>即可；
6）项目的继承（可以和聚合一同使用）
1）将公用的配置，放置到父项目的pom.xml中；
2）使用dependencyManagement对项目继承的依赖进行管理，如果直接使用<dependencys>子类则全部集成，可能导致无用的依赖；
3）子项目使用方式
引用方式：

<parent>
	<groupId>com.maven</groupId>
	<artifactId>user-parent</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<relativePath>../Maven_User_Parent/pom.xml</relativePath>
</parent>

依赖的应用：

<!-- 使用父pom中的dependency，这里可只写groupId、artifactId -->
<dependency>
	<groupId>commons-logging</groupId>
	<artifactId>commons-logging</artifactId>
</dependency>

7）版本的管理（x.x.x-xxx）
总版本号.分支版本号.小版本号-里程碑版本
总版本号的变动的一般表示框架的变动；
分支版本号的变动一般表示增加了一些功能；
小版本号表示在分支版本上进行bug的修复；
里程碑版本一般是如下的过程：SNAPSHOT（快照）-alpha（内测）-beta（公测）-release（发布版）-GA（General Availability）
（总版本号.分支版本号是必须的，而小版本号-里程碑版本可以不要）
8）生命周期
1）clean
pre-clean 执行一些需要在clean之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean之后立刻完成的工作
2）default
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如 JAR。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。
3）site
3、Maven的私有仓库的使用（详细见附件）
4、Maven的插件
1）插件
maven的核心，所有执行的操作都是基于插件来完成的；
为了让一个插件中可以实现众多的相类似的功能，maven为插件设定了目标，一个插件中有可能有多个目标；
其实生命周期中的重要的每个阶段都是由插件的一个具体目标来执行的；
常用插件
source（打包时打包源文件）；
help（直接在cmd中运行，查看插件的goals）：
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-help-plugin；
mvn help:describe -Dplugin=compiler -Ddetail（compiler为插件的前缀prefix）；

附注：
1、学习时参考的Maven的视频
http://pan.baidu.com/s/1eSqEC
2、附件：
1）Maven私有仓库Nexus的笔记：Maven_Nexus.zip
2）写过的一些代码，内部配置也有较详细的注释：Maven.zip