Maven入门及其使用

目录

一、Maven入门

1.1 初识Maven

1.2 Maven的作用

1.2.1 依赖管理

1.2.2 统一项目结构

1.2.3 项目构建

1.3 Maven坐标

1.4 Maven仓库

1.4.1 Maven仓库概述

二、Maven的下载与安装

2.1 安装步骤

2.1.1 解压安装（建议解压到没有中文、特殊字符的路径下。）

2.1.2 配置本地仓库

2.1.3 配置阿里云私服

2.1.4 配置Maven环境变量

三、IDEA集成Maven

3.1 配置Maven环境

3.1.1 当前工程设置

3.1.2 全局设置

3.2 创建maven项目

3.3 依赖管理

1、排除依赖

2、依赖范围

四、 Maven生命周期

---

一、Maven入门

1.1 初识Maven

Maven是apache旗下的一个开源项目，是一款用于管理和构建java项目的工具

1.2 Maven的作用

1.2.1 依赖管理

方便快捷的管理项目依赖的资源(jar包)，避免版本冲突问题

当使用maven进行项目依赖(jar包)管理，则很方便的可以解决这个问题。 我们只需要在maven项目 的pom.xml文件中，添加一段如下图所示的配置即可实现

1.2.2 统一项目结构

提供标准、统一的项目结构

具体的统一结构如下：

1.2.3 项目构建

maven提供了标准的、跨平台(Linux、Windows、MacOS) 的自动化项目构建方式

如上图所示我们开发了一套系统，代码需要进行编译、测试、打包、发布，这些操作如果需要反复进行 就显得特别麻烦，而Maven提供了一套简单的命令来完成项目构建

综上所述，可以得到一个结论：Maven是一款管理和构建java项目的工具

1.3 Maven坐标

坐标就是资源(jar包)的唯一标识，通过坐标可以定位到所需资源(jar包)位置， 使用坐标来定义项目或引入项目中需要的依赖

下图就是一个maven坐标，maven坐标由、、三个标签组成

groupId：定义当前Maven项目隶属组织名称（通常是域名反写，例如：com.itheima）

artifactId：定义当前Maven项目名称（通常是模块名称，例如 order-service、goods-service）

version：定义当前项目版本号 

            
                org.springframework.boot
                spring-boot-starter-mail
                3.2.1
            

1.4 Maven仓库

之前我们项目中需要jar包时，直接就把jar包复制到项目下的lib目录，而现在书写在pom.xml文件中 的坐标又是怎么能找到所要的jar包文件的呢？

答案：Maven仓库

1.4.1 Maven仓库概述

仓库：用于存储资源，管理各种jar包 仓库的本质就是一个目录(文件夹)，这个目录被用来存储开发中所有依赖(就是jar包)和插件

Maven仓库分为：

本地仓库：自己计算机上的一个目录(用来存储jar包)

中央仓库：由Maven团队维护的全球唯一的。仓库地址：Central Repository: (maven.org)

远程仓库(私服)：一般由公司团队搭建的私有仓库

当项目中使用坐标引入对应依赖jar包后，首先会查找本地仓库中是否有对应的jar包 如果有，则在项目直接引用 如果没有，则去中央仓库中下载对应的jar包到本地仓库 如果还可以搭建远程仓库(私服)，将来jar包的查找顺序则变为： 本地仓库 --> 远程仓库--> 中央仓库

二、Maven的下载与安装

认识了Maven后，我们就要开始使用Maven了，那么首先我们要进行Maven的下载与安装

下载地址：Maven – Download Apache Maven

2.1 安装步骤

Maven安装配置步骤：

2.1.1 解压安装（建议解压到没有中文、特殊字符的路径下。）

解压缩后的目录结构如下

bin目录 ： 存放的是可执行命令。（mvn 命令重点关注）

conf目录 ：存放Maven的配置文件。（settings.xml配置文件后期需要修改）

lib目录 ：存放Maven依赖的jar包。（Maven也是使用java开发的，所以它也依赖其他的jar 包）

2.1.2 配置本地仓库

1）在自己计算机上新一个目录（本地仓库，用来存储jar包）

2）进入到conf目录下修改settings.xml配置文件

2.1). 使用记事本软件，打开settings.xml文件，定位到53行

2.2). 复制标签，粘贴到注释的外面（55行）

2.3). 复制之前新建的用来存储jar包的仓库路径，替换掉标签体内容

2.1.3 配置阿里云私服

由于中央仓库在国外，所以下载jar包速度可能比较慢，而阿里公司提供了一个远程仓库，里面基本也 都有开源项目的jar包。

进入到conf目录下修改settings.xml配置文件：

1). 使用记事本软件，打开settings.xml文件，定位到160行左右

2). 在标签下为其添加子标签，内容如下：

阿里云私服地址

2.1.4 配置Maven环境变量

Maven环境变量的配置类似于JDK环境变量配置一样

1). 在系统变量处新建一个变量MAVEN_HOME

MAVEN_HOME环境变量的值，设置为maven的解压安装目录

2). 在Path中进行配置 PATH环境变量的值，设置为：%MAVEN_HOME%\bin

3). 打开cmd命令提示符进行验证，出现如图所示表示安装成功

mvn -v

三、IDEA集成Maven

我们要想在IDEA中使用Maven进行项目构建，就需要在IDEA中集成Maven

3.1 配置Maven环境

3.1.1 当前工程设置

1、选择 IDEA中 File => Settings => Build,Execution,Deployment => Build Tools => Maven

2、设置IDEA使用本地安装的Maven，并修改配置文件及本地仓库路径

Maven home path ：指定当前Maven的安装目录

User settings file ：指定当前Maven的settings.xml配置文件的存放路径

Local repository ：指定Maven的本地仓库的路径 (如果指定了settings.xml, 这个目 录会自动读取出来, 可以不用手动指定)

3、设置配置工程的编译版本为17 Maven默认使用的编译版本为5（版本过低）

上述配置的maven环境，只是针对于当前工程的，如果我们再创建一个project，又恢复成默认的配置 了。 要解决这个问题， 我们就需要配置全局的maven环境。

3.1.2 全局设置

1、进入到IDEA欢迎页面 选择 IDEA中 File => close project

点击所有设置 进行设置

这里所设置的maven的环境信息，并未指定任何一个project，此时设置的信息就属于全局配置信息。 以后，我们再创建project，默认就是使用我们全局配置的信息。

3.2 创建maven项目

3.3 依赖管理

依赖具有传递性

依赖传递可以分为：

1. 直接依赖：在当前项目中通过依赖配置建立的依赖关系

2. 间接依赖：被依赖的资源如果依赖其他资源，当前项目间接依赖其他资源

比如以上图中： projectA依赖了projectB。对于projectA 来说，projectB 就是直接依赖。 而projectB依赖了projectC及其他jar包。 那么此时，在projectA中也会将projectC的依 赖传递下来。对于projectA 来说，projectC就是间接依赖。

1、排除依赖

问题：之前我们讲了依赖具有传递性。那么A依赖B，B依赖C，如果A不想将C依赖进来，是否可以做到？

答案：在maven项目中，我们可以通过排除依赖来实现。

排除依赖：指主动断开依赖的资源。（被排除的资源无需指定版本）

依赖排除示例

maven-projectA依赖了maven-projectB，maven-projectB依赖了Junit。基于依赖的传递性，所以maven-projectA也依赖了Junit

使用排除依赖后

2、依赖范围

在项目中导入依赖的jar包后，默认情况下，可以在任何地方使用。

如果希望限制依赖的使用范围，可以通过标签设置其作用范围。

四、 Maven生命周期

Maven对项目构建的生命周期划分为3套（相互独立）：

clean：清理工作。

default：核心工作。如：编译、测试、打包、安装、部署等。

site：生成报告、发布站点等。

三套生命周期又包含哪些具体的阶段呢, 我们来看下面这幅图:

我们看到这三套生命周期，里面有很多很多的阶段，这么多生命周期阶段，其实我们常用的并不多，主要关注以下几个

• clean：清除上一次maven项目中生成target文件

• compile：编译项目源代码，生成target文件

• test：使用合适的单元测试框架运行测试(junit)

• package：将编译后的文件打包，如：jar、war等，打包后的文件存放在target目录下；

• install：安装项目到本地仓库

IDEA工具为了方便程序员使用maven生命周期，在右侧的maven工具栏中，已给出快速访问通道

生命周期的顺序是：clean --> validate --> compile --> test --> package --> verify --> install --> site --> deploy

我们需要关注的就是：clean --> compile --> test --> package --> install

说明：在同一套生命周期中，我们在执行后面的生命周期时，前面的生命周期都会执行。

思考：当运行package生命周期时，clean、compile生命周期会不会运行？

clean不会运行，compile会运行。 因为compile与package属于同一套生命周期，而clean与package不属于同一套生命周期