走进Maven

Maven

1.构建的主要环节

​ 1.清理：将之前编译得到的旧class文件删除，为下一次编译做准备

​ 2.编译：将Java文件编译成字节码文件

​ 3.测试：自动测试，自动调用junit

​ 4.报告：测试执行结果

​ 5.打包：动态Web工程打包成wsar包，普通Java工程jar包

​ 6.安装：将打包得到的文件复制到仓库中的指定位置

​ 7.部署：将war包复制到服务器指定目录下

2.安装Maven

1.官网下载安装包，找到一个没有中文的目录解压

2.配置环境变量

​ 1.检查JAVA_HOME

​ 2.配置Maven

​ MAVEN_HOME或M2_HOME

​ path

​ 3.cmd–>mvn - v

3.Maven核心概念

​ 1.约定的目录结构

​ 2.pom

​ 3.坐标

​ 4.依赖

​ 5.仓库

​ 6.生命周期，插座，目标

​ 7.继承

​ 8.聚合

4.第一个Maven工程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iGcZHp49-1617527975162)(D:\图片\QQ截图20210404164612.png)]

src : 源码

pom.xml ：Maven工程的核心配置文件

main : 存放主程序

test : 存放测试程序

java : Java源文件

resource : 存放框架或其他配置文件

5.常用命令

1.mvn compile：编译主程序

2.mvn.clean:清理

3.mvn test-compile:编译测试程序

4.mvn test:执行程序

5.mvn package：打包

注意：

执行maven命令，必须进入pom.xml所在目录

Maven工程所依赖的插件，并不包含在Maven核心程序中

​ 当我们执行Maven命令，如果需要某些插件，Maven主程序首先会到本地仓库中寻找

​ 如果没配置：C–》用户–》当前用户名一致的文件–》。M2

​ 配置就在配置路径下找

如果本地厂库找不到，就会联网去中央仓库寻找，并下载到本地仓库中

6.POM

pom：Project Object Model 项目对象模型

pom.xml:对于Maven工程，它是核心配置文件，与构建的所有配置都是在这个文件中配置

7.坐标

1.在Maven中的坐标

​ 1.:公司或组织的域名倒序+项目名

​ 2.:模块名

​ 3.:版本号

注意：

SNAPAHOT-不稳定版本或快照版本，表该项目处于开发状态，随时可能发生变化

RELEASE-代表稳定版本或发布版本，一般项目上线后都会改为RELEASE版本

8.仓库

1.分类

本地仓库：当前电脑上部署的Maven仓库，它是为当前电脑上的所有Maven工程服务的

远程仓库：

​ 私服：搭建在局域网中，为局域网中的Maven工程服务

​ 中央仓库：架设在互联网上，为全球所有的Maven工程服务

​ 中央仓库镜像：

2.仓库里面保存的内容
Maven自身所需的插件。

​ 第三方框架或工具的jar包

​ 我们自己开发的Maven项目

9.依赖

9.1依赖的传递性

通过快捷键：ALt+Ctrl+Shift+U调出Maven项目依赖关系

9.2依赖范围

test compile provided

compile依赖范围

• 主程序：有效
• 测试程序：有效
• 打包：参与
• 部署：参与

test依赖范围

• 主程序：无效
• 测试程序：有效
• 打包：不参与

provided依赖范围

• 主程序：有效
• 测试程序：有效
• 打包：不参与
• 部署：不参与，原本的依赖由服务器提供

9.3依赖原则

就近原则

先到先得原则

10.生命周期

具体步骤包括清理、初始化、编译、测试、打包、集成测试、验证、部署和生成站点。这些步骤几 乎适合所有的项目，也就是说，所有项目的管理构建过程都可以对应到这个生命周期上来。

Maven 在项目的构建过程中，只是在方向和步骤上面起到了管理和协调的作用。

Maven 在生命周期的每个阶段都设计了插件接口。用户可以在接口上根据项目的实际需要绑定第 三方的插件，做该阶段应该完成的任务，从而保证所有 Maven 项目构建过程的标准化。当然，Maven 对大多数构建阶段绑定了默认的插件，通过这样的默认绑定，又简化和稳定了实际项目的构建。

在执行编译前，我们需要清理旧的内容，清理完成后才能执行编译，编译后要进行测试，生成报告，报 告没有问题才能打包和安装，部署。 所以：各个构建环节顺序必须按照给定的顺序来执行，并且都依赖 于特定的插件。。

10.1Maven的三个生命周期

1.Clean Lifecycle:在进行项目构建前进行的一些清理工作

2.Default Lifecycle:构建的核心部分，如编译，测试，打包，安装，部署等。

3.Site Lifecycle: 生成项目报告，发布站点等

10.2Clean生命周期

1.pre-clean:执行一些需要在clean之前完成的工作

2.clean:删除上一次构建生成的文件

3.post-clean:执行一些需要在clean之后完成的工作

10.3Default生命周期

1.validate：验证，验证项目是否正确且所有必须信息是可用的

2.compile：编译，源代码编译在此阶段完成

3.Test：测试，使用适当的单元测试框架进行测试，例如JUnit。

4.package：打包，创建jar包 或 war包

5.verify：检查，对集成测试的结果进行检查，以保证质量达标

6.install：安装，安装打包的项目到本地仓库，以供其他程序使用

7.deploy：部署，拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工

10.4Site Lifecycle生命周期

1.pre-site:执行一些生成站点文档之前所要完成的工作

2.site:生成项目的站点文档

3.post-site:执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

4.site-deploy：将生成的站点文档部署到特定的服务器上

构建中生命周期的特点：无论你从生命周期的哪一步执行，Maven都会从该生命周期的第一步开始执行

11.插件和插件目标

1.生命周期的各个阶段仅仅定义了该阶段要执行的任务是什么

2.各个阶段和插件目标是对应的

3.相似 的目标有特定的插件组成

4.插件的目标也可以看作是调用插件命令

12.继承

比如项目中有3个模块

​ 模块1 依赖 Junit 4.1

​ 模块2 依赖于Junit 5.2

​ 模块3 依赖于Junit 5.3

由于test范围的依赖不能传递，所以这些插件必然分散在各个模块中，这样很容易造成版本的不一致， 所以我们现在需要统一管理各个模块中对Junit依赖的版本。

解决思路：

将Junit依赖统一提取到“父”工程中，在子工程中声明junit依赖时不指定版本，而版本号以父工程中统 一设定的为准，同时也方便后期维护

操作步骤：

1.创建一个Maven父工程。注意该工程打包方式为：pom方式

2.在子工程中声明对父工程的引用

3.在子工程中 声明对Junit的依赖，但不包含版本号信息

1.创建3个工程

maven-parent

• maven-archetype-site-simple

maven-dao

• maven-archetype-quickStrat

maven-service

• maven-archetype-quickStrat

2.在子工程的pom文件中添加继承关系

<!--声明父工程-->
<parent>
	<groupId>com.wdzl.maven</groupId>
	<artifactId>maven_parent</artifactId>
	<version>1.0-SNAPSHOT</version>
<!--以当前文件为基准的父工程pom.xml的相对路径-->
<relativePath>../maven_parent/pom.xml</relativePath>
</parent>

3.在父工程中配置依赖管理

<!-- 配置依赖管理-->
<dependencyManagement>
	<dependencies>
	 <dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>4.12</version>
		<scope>test</scope>
	 </dependency>
	</dependencies>
</dependencyManagement>

4.配置依赖管理之后，我们删除子工程中依赖的版本号

13.聚合工程

聚合工程可以一键安装各个模块工程，我们只需要在总聚合工程中配置聚合的模块即可 以继承的项目为例，我们在父工程的pom文件中添加需要聚合的子工程

    <modules>
        <module>../maven_service</module>
        <module>../maven_dao</module>
    </modules>