走进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>
标签:maven,插件,依赖,工程,走进,Maven,生命周期 来源: https://blog.csdn.net/deathseeks/article/details/115430841