【Maven】01 - 入门篇

【Maven】01 - 入门篇

安装maven，配置环境变量和配置setting.xml不再多说，网上多的是，非常简单

一：Maven依赖管理

最简单的依赖管理，总共就只有三步，如下：

1️⃣ 在pom.xml中，先写一个<dependencies>标签；

2️⃣ 在<dependencies>标签中，使用<dependency>标签来导入依赖；

3️⃣ 在<dependency>标签中，通过GAV坐标来导入依赖，而所谓的GAV坐标就是

• GroupID：组织ID，一般写公司的名称缩写；
• ArtifactID：当前Maven工程的项目名字；
• Version：当前Maven工程的版本。

<dependencies><!-- 这是一个示例 --><dependency><groupId>org.springframework</groupId><artifactId>spring-web</artifactId><version>5.1.8.RELEASE</version></dependency>
</dependencies>

现在有一个核心问题就是很多人知道自己想要引入什么依赖，但是不知道对应的groupId，下面提供两种方式

1. https://mvnrepository.com/ -> 这个是maven仓库，可以通过搜索查找自己的依赖，然后直接拷贝

2. 如果你使用的是IDEA，那么可以添加一个maven-search的插件，然后在pom.xml中右键，输入你想要添加的依赖，选择对应的版本之后，复制maven就可以了

二：刷新Maven

引入GAV坐标后，依赖不会立马生效，需要手动刷新一下项目，这里也是两种方式(都是以IDEA为例)：

1. 可以使用右上角maven的刷新图标

2. 可以安装maven-helper插件，在项目上右键，然后通过Run Maven里的指令刷新

三：依赖管理的范围

有时候，有些依赖我们并不希望一直有效，比如典型的JUnit测试包，对于这类jar包而言，最好只针对测试环境有效

这时可以使用<scope>属性控制依赖的生效范围

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><version>2.1.8.RELEASE</version><scope>test</scope>  <!-- 声明只对测试环境有效 -->
</dependency>

该标签共有五种取值方式，每种取值对应着一种依赖范围，而不同的依赖范围，生效的环境（classpath）也并不同

依赖范围	编译环境	测试环境	运行环境
compile（默认）	√	√	√
provided	√	√	×
system	√	√	×
runtime	×	√	√
test	×	√	×

项目引入的所有依赖，如果不显式指定依赖范围，默认是compile，意味着所有环境下都生效，而一般的依赖包也无需更改，只有某些特殊的依赖，才需要手动配置一下

四：Maven工作原理

在Maven中，节点会分为工程、仓库两大类，工程是“依赖使用者”，仓库是“依赖提供者”

• 中央仓库：就是配置的镜像源(maven的setting.xml)，里面拥有海量的公共jar包资源；
• 远程仓库：也叫私服仓库，主要存储公司内部的jar包资源(nexus)；
• 本地仓库：自己电脑本地的仓库，会在磁盘上存储jar包资源。

了解了三大仓库的概念，Maven的工作原理就非常清晰了：

🎉 在本地仓库中，GAV坐标和本地仓库的文件夹意义对应，所以只要你书写了正确的GAV坐标，就一定能够找到所需的依赖，并将其载入到项目中

五：Maven生命周期

在IDEA中，通过maven工具，可以非常清楚的看到maven有九种LifeCycle命令：

• clean：清除当前工程编译后生成的文件（即删除target整个目录）；
• validate：对工程进行基础验证，如工程结构、pom、资源文件等是否正确；
• compile：对src/main/java目录下的源码进行编译（会生成target目录）；
• test：编译并执行src/test/java/目录下的所有测试用例；
• package：将当前项目打包，普通项目打jar包，webapp项目打war包；
• verify：验证工程所有代码、配置进行是否正确，如类中代码的语法检测等；
• install：将当前工程打包，然后安装到本地仓库，别人可通过GAV导入；
• site：生成项目的概述、源码测试覆盖率、开发者列表等站点文档（需要额外配置）；
• deploy：将当前工程对应的包，上传到远程仓库，提供给他人使用（私服会用）。

上述的命令非常非常得常用，一定要对每一个命令的作用十分的熟悉！！！

主要注意核心工作周期(default)这一套，该生命周期涵盖了构建过程中的检测、编译、测试、打包、验证、安装、部署每个阶段

同一生命周期内，执行后面的命令，前面的所有命令会自动执行!!!

# test命令位于default这个生命周期内，所以它会先执行validate、compile这两个阶段，然后才会真正执行test阶段
mvn test

还可以一起执行多个命令

# 这两个命令隶属于不同的周期，所以会这样执行：
# 先执行clean周期里的pre-clean、clean，再执行default周期中，validate~install这个闭区间内的所有阶段。
mvn clean install

Maven插件会实现生命周期中的每个阶段，这也就是为啥IDEA中的Lifecycle下面，还会有个Plugins的原因

当你双击Lifecycle中的某个生命周期阶段，实际会调用Plugins中对应的插件

在Shell窗口执行mvn命令时，亦是如此，因为插件对应的实现包，都会以jar包形式存储在本地仓库里

有特殊的需求，也可以在pom.xml的<build>标签中，依靠<plugins>插件来导入