Maven安装和核心概念
一、maven安装
介绍了一下maven需要安装的环境，比如说：操作系统、jdk版本要求(maven是基于java编写的)、内存情况等等。
然后就是修改环境变量等等信息。
附上一个学习连接：https://www.runoob.com/maven/maven-tutorial.html
安装完成之后，查看是否安装成功
二、Maven约定
要想使用maven，maven就给使用者定义规范，要求使用者来遵守规范。
1、必须有pom.xml文件
<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.codehaus.mojo</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
</project>
坐标：每个项目都需要有一个坐标，因为通过坐标可以定位到一个项目。坐标由三部分组成：
groupId：分组id，一般表示项目组织id，是哪个组织编写的
artifactId：当前项目的名称【约定】
version：当前项目的版本号。有SNAPSHOT(快照版)和RELEASE(发行版)
ps：
如果是引入外部的jar包，这里对应的是本地仓库中的位置，可以从本地仓库中找到。
3、编写java源文件位置
maven要求，要求在src/main/java目录下来编写源代码
3、编译class文件位置
maven要求，编译后的class会放置在target/class目录下
将源代码编译之后，会放置到target/clases目录下。
4、配置文件位置
maven要求配置文件写在src/main/resources目录下
配置文件在参与编译阶段之后，也会放置到类路径下
5、测试方法
要想让maven来跑我们的测试用例代码，测试类必须要在src/test/java目录下且以Test开头，测试类中的方法必须要以test开头
方法不要有返回值。
然后执行mvn test跑测试方法
在测试方法运行之后，会在控制台展示：正在测试哪个类，正在测试的成功数量，错误和跳过的。
在surefire-reports下会生成测试报告等等。有xml文件和txt文件等等条件。
6、使用junit依赖测试
首先需要在pom中引入依赖，官方上有一个，直接拿下来用。直接在pom文件中来进行添加
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<type>jar</type>
<scope>test</scope>
<optional>true</optional>
</dependency>
</dependencies>
刷新maven，将依赖引入进来。
junit测试
maven约定：如果引入了junit包依赖，那么上面的测试约定就作废了，失效了。也就是说，方法、类名都可以不以test开头了。
即使不以test开头，依然是可以来进行运行的。
还可以针对里面的异常信息来做判断：
因为这里测试的1和1是不想等的，所以这里会报错。
三、依赖管理
依赖管理就是引入外界的，也就是第三方的jar包到当前项目中来。
在学习web的时候，我们处理第三方jar包的时候，是添加到web/lib目录下来进行管理。
而maven引入了包的依赖管理，方便我们来管理我们的引入的jar包。
maven中jar包位置
maven会先从本地仓库找，本地仓库找不到会从远程仓库下载。
正常开发过程中，首次使用maven的时候，去下载jar包的时候，本地肯定都是没有的，肯定都是从远程仓库来进行下载。
本地仓库
本地仓库是下载安装了maven之后，maven会给我们自动指定的。
找到maven的安装位置，我的是在C:\work\software\java\maven\conf，然后找到这个目录下的settings.xml配置文件。
搜索关键字：localRepository
看到一行配置：
<!-- 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:/mavenr</localRepository>
默认是在当前用户目录下的.m2目录下的repository目录。
但是可能因为我们的C盘文件太小，或者是以为用户被注销了，导致无法使用本地仓库的情况，所以建议将本地仓库建立在其他目录下。
我这里选择建立的是在D盘下的mavenr目录下。
远程仓库
远程仓库一般来说，分为两种：公司自己搭建的仓库和maven中央仓库(但是在国外，下载速度较慢)
在私服中的jar包，是由开发人员手动来进行上传的。
私服一般是用来存当前公司中开发出来的公共组件，可以依赖的组件放入到私服中，让其他项目来引入。这种方法比较可取。
Maven核心配置
主要分为三个部分：
- 1、项目依赖（内部和外部）
- 2、项目聚合和继承
- 3、项目构建和配置
一、项目依赖
当前项目可能会依赖其他的项目，这里说的其他的项目，可能是简单的jar包，也可能是一个项目jar包，在体量上没有限制。
对于依赖的组件，maven通过maven特性来管理项目中引入的依赖
- 1、依赖传播
- 2、依赖优先原则
- 3、可选依赖
- 4、排除依赖
- 5、依赖范围
1、依赖传递
下面将会通过SpringMVC的依赖来做一个示范。
在idea中有一个快捷键，可以来查看当前项目的依赖图
下面拿commons-logging来举例子，当前的commons-logging版本可以在External Libiaries下面可以看到
当前版本是1.2
那么下面接着在pom文件中引入另外一个版本中的commons-logging版本
引入依赖之后，发现当前的commons-logging版本变成了最新的版本了。
maven依赖-就近原则
上面描述的就是就近原则，那么怎么来理解呢？再来生成对应的依赖树结构看下：
从这里可以看到，如果不引入commons-logging坐标，test项目需要依赖commons-logging的话，那么需要经过spring-webmvc来进行依赖。
但是我们新添加了commons-logging坐标之后，test项目就不需要经过spring-webmvc，而是直接依赖上了commons-logging
蓝色线条表示的是只有单个依赖，红色线条表示的是出现了多个依赖
也就是红色线条表示的信息，项目直接依赖了commons-logging，而spring-webmvc也依赖的是commons-logging
test项目直接使用了1.1.3版本
就近原则也就是说，当前项目依赖了同一个依赖，哪个依赖离当前项目越近，maven就会选择来利用哪一个依赖。
最短路径优先。
maven依赖-优先原则
相对于就近原则来说，如果路径是一样的，那么该选择哪一个依赖呢？
这也是经常会出现的一种问题。
一个项目依赖了另外一个项目，但是这两个项目有着同样的一种依赖。那么就有可能导致出现问题。
所以为了避免这种问题，spring也定义了一个规则：如果是路径一致，那么谁先配置，就使用谁的。
来模拟一种场景
分别看下两个的pom文件：
server.xml
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.1.8.RELEASE</version>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>client</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
client.xml
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>5.3.4</version>
</dependency>
</dependencies>
直接查看server的依赖树
对于server来说，依赖的spring-webmvc，需要依赖spring-web；
对于client来说，是直接依赖了spring-web的。
但是对于server来说，因为从server到spring-web的路径都是一样的。那么maven这时候是如何选择的？
根据谁先引入，选择谁。而在server.pom中，先引入的是client，所以当前的版本应该是5.3.4版本
那么我在这里，我更改一下顺序，再看一下：
<dependencies>
<dependency>
<groupId>org.example</groupId>
<artifactId>client</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.1.8.RELEASE</version>
</dependency>
</dependencies>
修改了对应的顺序之后
可以看到现在依赖的是4.1.8的版本了。
看这里的黑线即可分辨出来依赖的是哪一个。
maven依赖-顺序原则
直接来看比较好：
后面的会覆盖掉前面的。
可选依赖
也可以用于上面的情况，比如在client中，设置spring-web为可选依赖，这样子，当client被server引入之后，就是可选可不选。
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>5.3.4</version>
<optional>true</optional>
</dependency>
</dependencies>
那么这个时候看一下server的依赖结构
这个时候，发现没有依赖使用到client中的，但是不影响server的使用。
排除依赖
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.1.8.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</exclusion>
</exclusions>
</dependency>
在当前版本中，排除对当前版本中对spring-web的依赖，而去依赖于其他的选项。
依赖范围
一些依赖在打包的时候没有必要打包进去，例如junit，只有在测试的时候才会用到。
maven可以通过scope属性来决定作用域范围，maven一共支持四种：
- compile：默认的作用域范围，在编译和打包都会依赖；
- provided：编译时会依赖，但是不会打包进去。如servlete-api
- runtime：打包时依赖，但是编译不会。如Mysql-connector
- test：测试范围，编译运行测试用例依赖，但是不会打包进去
- system：作用域由操作系统作用域决定。
二、聚合和继承
聚合是相当于父工程来说的，继承是相当于子项目来说的。
聚合在父工程中，一般都是选择版本号、插件等等；
但是依赖管理采用的使用
<dependencyManagement></dependencyManagement>
这样子的好处是让子类有选择的继承父类中的依赖，还不需要来使用版本号就可以使用了。
