Maven的学习笔记
自动化构建工具 Maven
构建过程中的各个环节
- 清理：将以前编译得到的旧的class字节码文件删除，为下一次编译做准备
- 编译：将java源程序编译成class字节码
- 测试：自动测试，自动调用junit程序
- 报告：测试程序执行的结果
- 打包：动态Web工程打war包，java工程打jar包
- 安装:Maven特定的概念——将打包得到的文件复制到"仓库"中的指定位置
- 部署：将动态Web工程生成的war包复制到Servlet容器的指定目录中，使其可以运行
安装Maven核心程序
1. 检查jdk安装环境变量
2. 解压Maven核心程序的压缩包，放在一个非中文无空格路径下(减少另类问题)
3. 配置Maven相关的环境变量
- Maven_HOME 或 M2_HOME
- M2_HOME 是在解压文件下就行
- path添加的是解压文件里面的bin目录下
4. 验证：运行mvn -v 命令查看Maven版本
5. Maven的核心概念
1. ==约定的目录结构==
2. ==POM==
3. ==坐标==
4. ** *依赖***
5. 仓库
6. 生命周期/插件/目标
7. 继承
8. 聚合
6. 创建Maven工程
1. 创建约定的目录结构
1. 根目录
2. src目录
3. pom.xml文件： Maven的配置文件
4. main目录
5. test目录
6. java目录
7. resources目录
2. 必须要遵循按照上面的目录结构，不然会找不到，
7. 常用的Maven命令
1. 注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录与构建过程相关：编译，测试，打包.......
2. 常用的命令
1. mvn clean ：清理
2. mvn compile ： 编译主程序
3. mvn test-compile : 编译测试程序
4. mvn test ： 执行测试
5. mvn package ：打包
6. mvn install : 安装
7. mvn site : 生成站点
8. 联网的问题
1. Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成，而插件本身并不包含在Maven的核心程序中
3. 当我们执行的Maven命令需要用到某些插件时，Maven核心陈程序会首先到本地仓库中查找
4. 本地仓库的默认位置：[系统中当前用户的家目录]\.m2\repository
5. 如果在本地仓库中找不到需要的插件，那么它会连接到外网，到中央仓库下载
6. 修改默认本地仓库的位置，可以让Maven找到事先准备好的目录下查找插件
1. 找到Maven解压目录\conf\setting.xml
2. 在setting.xml文件中找到localRepository标签
3. 将<localRepository>/path/to/local/repo</localRepository>内容移到注释外，改成本地仓库
9. POM
1. 含义：Project Object Mode 项目对象模型
2. pom.xml对于是Maven是核心配置文件，相当于web.xml
10. 坐标
1.Maven坐标
- 使用下面三个向量在仓库中唯一定位一个Maven工程
1. groupid ： 公司或组织域名倒序 + 项目名
2. artifactid ： 模块名
3. version ： 版本号
```
例子
<groupId>com.maven.demo</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SHAPSHOT</version>
```
2. Maven工程的坐标与仓库中路径的对应关系
11. 仓库
1. 仓库的分类
1. 本地仓库
2. 远程仓库
- 私服 ： 局域网Nexus
- 中央仓库 ： Internet上的
- 中央仓库镜像 ：架设在各个大洲，分担中央仓库流量
3. 仓库中保存的内容： Maven工程
- Maven自身所需要的插件
- 第三方框架或工具的jar包
- 自己开发的Maven工程
12. 依赖
1. Maven解析依赖信息会到本地仓库区寻找依赖的jar包
- 对于自己开发的Maven工程，使用install命令安装后就可以进入仓库
2. 依赖的范围
1. compile
- 对主程序是否有效 ： 1
- 对测试程序是否有效 ：1
- 是否参与打包 ： 1
2. test
- 对主程序是否有效 ： 0
- 对测试程序是否有效 ：1
- 是否参与打包 ： 0
3. provied
- 对主程序是否有效 ： 1
- 对测试程序是否有效 ：1
- 是否参与打包 ：0
- 是否参与部署： 0
- 典型的例子：Servlet-api.jar
13. 声明周期
1. 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
2. Maven的核心程序中定义了抽象的生命手气，生命周期中各个阶段的具体任务是由插件来完成的，
3. Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中的各个阶段：不论现在要执行生命周期汇总的哪一个阶段，都是从这个生命周期最初的位置开始执行。
4. 插件和目标
1. 生命周期的各个阶段仅仅定义了要执行的任务是什么。
2. 各个阶段和插件的目标是对应的的
3. 相似的目标由特定的插件来完成
4. 可以将目标，看成插件使用
14. 依赖高级
1. 依赖的传递性
1. 好处 ： 可以传递不必在每个模块工程中都重复使用
2. 主义：非compile范围的依赖不能传递
3. 需要设置依赖排除的场合
2. 依赖的排除方式
在pom文件中添加
```
<exclusions>
<exclusion>
<groupId>...</groupId>
<artifactId>...</artifactId>
</exclusion>
</exclusion>
```
3. 依赖的原则
1. 作用：解决模块工程之间的jar包冲突问题
2. 验证路径最短者优先原则
3. 验证路径相同时先声明者优先
4. dependeny 是声明顺序
4. 统一依赖的版本
- 建议配置方式
1. 使用properties标签统一声明版本号
2. 在需要统一版本的位置，使用${自定义标签}引用声明的版本号
3. 上面的两个功能不至如
15. 继承
1. 需求 ： 统一管理各个模块对包依赖的版本
2. 解决思路：将包依赖统一提取到父工程，在子工程中声明包依赖时不指定版本，以父工程统一设定为准
3. 然后删除子工程的版本号
4. **注意 ： 配置继承后，执行安装命令时要先安装父工程**
- 聚合
- 作用 ： 一键安装各个模块工程
- 配置方式 ： 在一个"总的工程"中配置参与聚合的模块
- 例子
<modules> <module>执行各个子工程的相对路径</module> <!--最好以依赖的顺序来排列--> </modules>- 使用方式：在聚合工程的pom文件然后maven install
16. 工程的特殊配置
```
<!--配置当前工作构建过程中的特殊配置-->
<build>
<finalName>Atweb</finalName>
<!--配置构建过程中需要使用的插件-->
<plugins>
<plugin>
<!--cargo是一家专门从"启动Servlet容器"的组织-->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>1.1.2</version>
<!--针对插件进行的配置-->
<configuration>
<!--配置当前系统中容器的位置-->
<container>
<containerId>..</containerId>
<home>...</home>
</container>
</configuration>
<!--配置插件在什么地方实行-->
<executions>
<execution>
<id>...</id>
<!--生命周期的阶段-->
<phase>install</phase>
<goals>
<!--插件的目标-->
<goal>run</goal>
</goals>
<!--上面就是执行到install阶段的时候，执行goal里面包含的插件-->
</execution>
</executions>
</plugin>
</plugins>
</build>
```
**上面的这个有的技术已经是不适合在用了，因为有强大的IDE了**
17. Maven酷站
可以到这个网站去搜索需要的jar包
(https://mvnrepository.com/)