Maven的部署及使用
一、Maven的常用命令
mvn compile
执行这个命令会生成target目录，里面存放有java源代码编译后的.class文件，target目录用来存放构建的结果
mvn test-compile
执行这个命令会在target目录里面生成test-classes子目录，用来存放测试程序编译后的.class文件
mvn package
mvn clean
执行清除命令，清除target目录
mvn install
安装Maven工程到本地仓库中
mvn site
安装站点
二、Maven的核心概念
约定的目录结构
从前面介绍的过程来看，只要将项目的源文件按Maven要求的规范组织，并提供pom.xml文件，即使pom.xml文件中只包含极少的信息，也依然可以使用Maven来编译项目、运行程序，甚至可以运行测试用例、打包项目，这是因为Maven采用了”约定优于配置（Convention over Configuration，CoC）”的原则，根据此原则，Maven的主要约定有如下几条：
- 源代码应该位于
${basedir}/src/main/java路径下 - 资源文件应该位于
${basedir}/src/main/resourse路径下 - 测试代码应该位于
${basedir}/src/test路径下 - 编译生成的
.class文件应该位于${basedir/target/classes}路径下 - 项目应该会产生一个
JAR文件，并将生成的JAR包放在${basedir}/target路径下
POM
Project Object Model项目模型，pom.xml对于Maven工程是核心的配置文件，与构建相关的一切设置都在这个配置文件中进行设置，重要程度相当于web.xml配置文件对于动态的Web工程的重要性。
坐标
Maven中的坐标使用下面三个向量在仓库中唯一定位一个Maven工程
groupId：公司或组织域名倒序+项目名artifactId：模块名version：版本号
Maven工程的坐标与仓库中路径具有一一对应关系
spring-core-4.0.0.RELEASE.pom文件的坐标
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
实际磁盘目录的路径为
仓库
-
本地仓库：为当前本机电脑上的所有 Maven 工程服务
-
远程仓库
私服：架设在当前局域网环境下，为当前局域网范围内的所有 Maven 工程服务。
中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务。
中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。 -
仓库中的文件
Maven自身所需要的插件
第三方框架或工具额jar包
自己开发的Maven工程
依赖
Maven解析依赖信息时会到本地仓库去查找被依赖的jar包，如果没有找到所依赖的jar包就会报错
而对于自己开发的Maven工程可以执行mvn install添加到仓库中
依赖的范围
-
compile：编译范围的依赖，对于主程序和测试程序都有效，并且参与打包。 -
test：测试范围的依赖，对于主程序是无效的，主程序感觉不到测试范围的依赖的存在，但对于测试程序是有效的，并且测试范围的依赖不参与打包。 -
provided：对于主程序是有效的对于测试程序也是有效的，但是不参与打包，即不参与部署。
从开发和运行这两个不同阶段理解 compile 和 provided 的区别：
compile范围的依赖需要在开发、部署、运行时使用，并且需要把这个依赖放到Tomcat服务器上
provided范围的依赖在开发时需要，一般都是一些Servlet的依赖，但是在部署和运行时不需要，因为Servlet的依赖早已经在服务器上存在，在运行时由Servlet容器提供。
生命周期
构建过程中的各个环节：
- 清理：删除以前的编译结果，为重新编译做好准备。
- 编译：将 Java 源程序编译为
.class字节码文件。 - 测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
- 报告：在每一次测试后以标准的格式记录和展示测试结果。
- 打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应
jar包，Web工程对应war包。 - 安装：在 Maven 环境下特指将打包的结果——
jar包或war包安装到本地仓库中。 - 部署：将打包的结果部署到远程仓库或将
war包部署到服务器上运行。
对于构建环节必须按照这个顺序来，不能打乱顺序。Maven的核心程序中定义了抽象的生命周期，但生命周期中各个阶段的具体任务是由插件来完成的。
Maven 有三套相互独立的生命周期，分别是：
Clean Lifecycle在进行真正的构建之前进行一些清理工作。Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。Site Lifecycle生成项目报告，站点，发布站点。
Clean 生命周期：
pre-clean执行一些需要在clean之前完成的工作clean移除所有上一次构建生成的文件post-clean执行一些需要在clean之后立刻完成的工作
Site 生命周期：
pre-site执行一些需要在生成站点文档之前完成的工作site生成项目的站点文档post-site执行一些需要在生成站点文档之后完成的工作，并且为部署做准备site-deploy将生成的站点文档部署到特定的服务器上
Default 生命周期：
validategenerate-sourcesprocess-sourcesgenerate-resourcesprocess-resources复制并处理资源文件，至目标目录，准备打包。compile编译项目的源代码。process-classesgenerate-test-sourcesprocess-test-sourcesgenerate-test-resourcesprocess-test-resources复制并处理资源文件，至目标测试目录。test-compile编译测试源代码。process-test-classestest使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。prepare-packagepackage接受编译好的代码，打包成可发布的格式，如 JAR。pre-integration-testintegration-testpost-integration-testverifyinstall将包安装至本地仓库，以让其它项目依赖。deploy将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。
Maven核心程序为了更好的实现自动化构建，在执行生命周期的各个阶段时，无论现在要执行生命周期中的哪一个阶段，都是从这个生命周期最初始的位置开始执行。
插件和目标：
- 生命周期的各个阶段仅仅定义了要执行的地任务是什么
- 各个阶段和插件的目标是对应的
- 相似的目标有特定的插件来完成，可以将目标看作是调用插件功能的命令
依赖的传递性
当添加某个依赖的时候，也会自动导入它所依赖的其它jar包
如果当前Maven工程A被另一个Maven工程B所依赖，当A工程导入依赖的时候，因为B工程依赖A工程，所以B工程也会自动导入A工程导入的依赖。这就是依赖的传递性。
依赖的传递性到带来的好处就是，可以传递的依赖不必在每个模块工程中都重复声明，只需要在最基础的工程中依赖一次即可，其它模块需要的话会自动导入。但是非compile范围的依赖不能传递。
依赖的排除
如果想排除掉导入某些依赖时，自动导入的其附带依赖，可以使用
依赖的原则
-
依赖就是解决模块工程之间的
jar包冲突的问题。 -
当因为依赖的传递性传递了两个相似(仅版本号不同)的jar包的时候，采取的是最短路径优先的原则。
-
如果依赖的两个相似的
jar包路径相同，就会采取先声明dependency标签的那个依赖。
统一管理依赖的版本
如果需要统一升级jar包的版本号，可以在
<properties>
<test_maven_version>4.0.0.RELEASEtest_maven_version>
properties>
然后在需要统一版本的位置，使用${自定义标签名}引用声明的版本号
<version>${test_maven_version}version>
继承
test范围的依赖由于不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。要想统一管理各个模块工程中不能传递的依赖的版本，可以将依赖统一提取到“父”工程中，在“子”工程中声明依赖时不指定版本，以父工程中统一设定的为准，同时也便于修改。
创建父工程，打包方式处要设置为 pom。
<packaging>pompackaging>
在子工程中引用父工程
<parent>
<groupId>mavendemo1groupId>
<artifactId>ParentartifactId>
<version>0.0.1-SNAPSHOTversion>
<relativePath>../Parent/pom.xmlrelativePath>
parent>
在父工程中管理依赖
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.9version>
<scope>testscope>
dependency>
dependencies>
dependencyManagement>
在子项目中重新指定需要的依赖，删除范围和版本号
<dependencies>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
dependency>
dependencies>
聚合
将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。可以在一个“总的聚合工程”中配置各个参与聚合的模块。
<modules>
<module>../Hellomodule>
<module>../HelloFriendmodule>
<module>../MakeFriendsmodule>
modules>