Maven-核心

一、Maven核心概念

1. POM
2. 约定的目录结构
3. 坐标
4. 依赖
5. 仓库
6. 生命周期
7. 插件和目标
8. 继承
9. 聚合

1.1 POM

Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。

1.2 约定的目录结构

JavaEE开发领域普遍认同一个观点：约定>配置>编码。能用配置不敲代码，能基于约定的就不进行配置

1.3 坐标

1. groupId：公司或组织的域名倒序+当前项目名称
2. artifactId：当前项目的模块名称
3. version：当前模块的版本

1.4 依赖管理

当A jar包需要用到B jar包中的类时，我们就说A对B有依赖，其中若A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。

1.5 依赖的范围

1. compile(默认)：test和main目录下的Java代码可以访问，且主工程对间接依赖的jar可以访问，部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下，
2. provided：test和main目录下的Java代码可以访问，部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
3. test：test目录下可以访问，main目录下不可以访问，部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
4. 其他：runtime、import、system等。
   

1.6 依赖的原则

1. 路径最短者优先
   
2. 路径相同时先声明者优先(先后顺序指的是dependency标签配置的先后顺序。)
   

1.7 依赖的排除

当工程A直接依赖B和commons-logging的1.1.2，B直接依赖commons-logging的1.1.1，那么A间接依赖commons-logging的1.1.1，那么若A不想间接依赖commons-logging的1.1.1,就可以用依赖排除

1.8 统一管理

以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-context，springmvc等jar包。我们应该导入版本一致的Spring jar包(实际上只要导入一个context其他的会自动导入)，而不是使用4.0.0的spring-context的同时使用4.1.1的springmvc。

1.9 仓库

仓库的分类：

1. 本地仓库：为当前本机电脑上的所有Maven工程服务。
2. 远程仓库：
   2.1 私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。
   
   2.2 中央仓库：架设在Internet上，为全世界所有Maven工程服务。
   2.3 中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。

仓库中的文件：

1. Maven的插件
2. 我们自己开发的项目的模块
3. 第三方框架或工具的jar包

二、生命周期

1. Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构建命令了。
2. 每套生命周期都由一组阶段(Phase)组成,
3. 它们是相互独立的
4. 可使用mvn clean单独运行clean
5. 可以使用mvn clean install site 运行所有这三套生命周期

2.1 三套独立的生命周期

1. Clean Lifecycle在进行真正的构建之前进行一些清理工作。
2. Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。
3. Site Lifecycle生成项目报告，站点，发布站点。

2.2 Clean生命周期

1. pre-clean 执行一些需要在clean之前完成的工作
2. clean 移除所有上一次构建生成的文件
3. post-clean 执行一些需要在clean之后立刻完成的工作

2.3 Site生命周期

1. pre-site 执行一些需要在生成站点文档之前完成的工作
2. site 生成项目的站点文档
3. post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
4. site-deploy 将生成的站点文档部署到特定的服务器上

2.4 Default生命周期

2.4.1 validate

1. generate-sources
2. process-sources
3. generate-resources
4. process-resources 复制并处理资源文件，至目标目录，准备打包。

2.4.2 compile

编译项目的源代码

1. process-classes
2. generate-test-sources
3. process-test-sources
4. generate-test-resources
5. process-test-resources 复制并处理资源文件，至目标测试目录。

2.4.3 test-compile

编译测试源代码

process-test-classes

2.4.4 test

使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。

prepare-package

2.4.5 package

接受编译好的代码，打包成可发布的格式，如JAR。

1. pre-integration-test
2. integration-test
3. post-integration-test

2.4.6 install

将包安装至本地仓库，以让其它项目依赖。

2.4.7 deploy

将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

2.4.8 小结

运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven为什么能够自动执行构建过程的各个环节的原因。此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要。

三、插件和目标

1. Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
2. 每个插件都能实现多个功能，每个功能就是一个插件目标。
3. Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
4. 例如：compile就是插件maven-compiler-plugin的一个功能；pre-clean是插件maven-clean-plugin的一个目标。

四、继承

由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。例如：

此时如果项目需要将各个模块的junit版本统一为4.9，那么到各个工程中手动修改无疑是非常不可取的。使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。

4.1 创建父工程

父工程的打包方式为pom(父工程只需要保留pom.xml文件即可)

4.2 在子共工程中引用父工程

此时如果子工程的groupId和version如果和父工程重复则可以删除。

4.3 在父工程中管理依赖

在子项目中重新指定需要的依赖，删除范围和版本号：

五、聚合

1. 将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装、清理工作。
2. Maven可以根据各个模块的继承和依赖关系自动选择安装的顺序

六、通过Maven创建Web工程

1. 创建简单的Maven工程，打包方式为war包
   
2. 点击Project Structure
   
3. 选择对应的Module，添加web目录
   
4. 设置目录名称
   
5. 在web目录下创建index.jsp页面
   
6. 部署到Tomcat上运行
   
   6.2 添加一个TomCat
   
   6.3 添加路径
   
   6.4 将项目添加到服务器上
   6.5 设置路径
   
   6.6 运行
   

七、Life

有人教你温柔成熟，可真正爱你的人，会教你做个小孩子