[Maven]讲讲它的构建生命周期和拉取 jar 包流程

最新推荐文章于 2023-05-25 09:15:00 发布

郑璐璐

最新推荐文章于 2023-05-25 09:15:00 发布

阅读量1k

点赞数

文章标签： maven 生命周期

本文链接：https://blog.csdn.net/zll_0405/article/details/114176603

版权

➤其他专栏收录该内容

46 篇文章 1 订阅

订阅专栏

我们都知道, Maven 是一款非常优秀的软件项目管理 & 自动构建的工具,相信各位在项目中都多多少少接触过
那么今天咱们就来扒一扒它的构建生命周期都有哪些,以及拉取 jar 包时它的一个流程是怎样的

Maven 生命周期

说到 Maven 的构建生命周期,我的小脑瓜里面冒出来的就是: clean install deploy 这些了
但是其实 Maven 生命周期不仅仅是这些~

Maven 整个生命周期大概可以分为三大类:

clean : 目的在于清理项目
default : 目的在于构建项目
site : 目的在于建立项目站点

其中 default 生命周期它的目的在于构建项目,所以详细来说又可以再分:

validate: 验证要构建的项目是正确的,并且所需要的资源是存在的
compile: 编译项目中的 java 文件成为虚拟机能识别的 .class 字节码文件
test: 使用合适的单元测试框架来测试编译的源码是否可以正确运行
package :将编译后的源代码打包( jar 或者 war )
verify: 验证测试结果确保达到目标
install: 将 package 放到本地仓库中,用作本地其他项目的依赖项
deploy: 在构建环境中完成之后,将最终的 package 传到远程仓库中,便于共享

我经常用的 Maven 生命周期就是刚开始我的小脑袋瓜就冒出来的那几个了: clean install deploy
但是现在 idea 和 Maven 已经有了一个非常完美的配合了,所以一般都是直接在 idea 里面操作,这些命令说起来也是很久没用过了

拉取 jar 包流程

讲完了 Maven 的生命周期,接下来说说,当我们使用 Maven 时,它是如何帮助我们拉取 jar 包的
首先上一张图:(问我为啥都是英文么?因为这样显得我很有文化的样子嘛~
在这里插入图片描述

接下来分析一下它的整个流程
local repository 就是本地仓库啦,在项目中使用到的 jar 包如果本地仓库中有,那就好了,什么都不用做,直接引用就 OK 了
但是如果本地仓库中没有呢?
有两种方法可以找到

第一种就是直接在我们项目中的 pom.xml 文件中,写上使用到的 <repository> <pluginRepository> , Maven 就会根据这个路径去找到要下载的 jar 包,但是这种方式我们一般都不怎么使用,因为我们更喜欢在 pom.xml 文件中以这样的方式使用:

	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>

		<dependency>
			<groupId>com.google.guava</groupId>
			<artifactId>guava</artifactId>
			<version>23.0</version>
		</dependency>
	</dependencies>

第二种方法就是我们常见的,将使用到的仓库地址存放在 Maven 的 setting 文件中,例如这样定义:

		<mirror>  
			<id>alimaven</id>  
			<name>aliyun maven</name>  
			<url>http://maven.aliyun.com/nexus/content/groups/public/</url>  
			<mirrorOf>central</mirrorOf>          
        </mirror>

当需要的 jar 包本地仓库没有时,就会通过 Maven 中的 setting 文件,我们设置的 mirror 通过 Repository Manager 找到镜像仓库,再通过分组/版本等信息,定位到我们想要的 jar 包
镜像仓库肯定都是公共的嘛,也就是 central repository ,然后肯定也会去做 cdn 处理,也就是 central CDN ,那么问题就是 central repository 中的相关数据是从哪里来的呢
是从 project-dedicated staging repositories (专用于项目的暂存库) 中同步过来的,我的理解就是:这个仓库是专用于项目的,然后经过大量项目的实践验证之后的 jar 包,会同步到 central data 中,再由 central data 向下同步,同时 central data 中的数据,也会 push (推送)到 public forges(multi-projects) staging repositories (公共库) 中
这样整个流程就建立起来了

扩展: 推送 jar 包到私服

我记得原来折腾 Maven 的时候,弄过怎么推送 jar 包到私服(当时搭建的私服是 Nexus ),当时也记录了一些东西,放在这里当个扩展内容吧

推送 jar 包到私服,主要有两种方式:

使用命令推送 jar 包
通过私服界面进行手动推送

接下来详细讲讲该如何推送,在这里以向 Nexus 推送为例

在使用命令推送 jar 包时,要在私服界面上允许远程推送,具体设置如下图:
在这里插入图片描述
设置完之后,再使用下面的命令就可以推送了
mvn deploy:deploy-file -Dmaven.test.skip=true -Dfile=C:\test\tool-1.0.jar -DgroupId=com.example -DartifactId=tool -Dversion=1.0 -Dpackaging=jar -DrepositoryId=thirdparty -Durl=http://192.168.163.129:8081/nexus/content/repositories/thirdparty/

其中一些字段的含义是:

-Dmaven.test.skip=true                      //跳过编译、测试
-Dfile=C:\test\tool-1.0.jar                 //jar包文件地址,绝对路径
-DgroupId=com.example                       //gruopId--pom坐标，自定义
-DartifactId=tool                           //artifactId--pom坐标，自定义
-Dversion                                   //版本号
-Dpackaging                                 //打包方式
-DrepositoryId                              //远程库服务器ID
-Durl                                       //远程库服务器地址