Maven - 自动化构建工具

高超不爱笑

已于 2024-03-19 09:47:11 修改

阅读量234

点赞数

分类专栏：开发工具文章标签： maven

于 2020-08-07 19:38:27 首次发布

本文链接：https://blog.csdn.net/weixin_45453240/article/details/107850456

版权

开发工具专栏收录该内容

10 篇文章

订阅专栏

问题引入

项目需要大量的第三方jar包，同样的jar包重复出现在不同的项目工程中，使工程臃肿且浪费空间，使用 Maven可以将其保存在仓库中，需要时引用文件接口
jar包之间存在依赖关系，导入的 jar 包可能不足，Maven 可自动的将当前 jar 包所依赖的其他所有 jar 包全部导入进来
项目所需jar包需到官网下载且种类繁多，使用 Maven 我们可以享受到一个完全统一规范的 jar 包管理体系。只需在项目中以坐标的方式依赖一个 jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个 jar 包所依赖的其他 jar 包
项目庞大，不适合使用package划分模块，借助Maven可以将项目拆分成多个工程协同开发，使用 Maven 的依赖管理机制进行工程间的互相调用和访问

上层模块依赖下层，所以下层模块中定义的 API 都可以为上层所调用和访问

概述

Maven 是一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理
构建：构建并不是创建，创建一个工程并不等于构建一个项目，构建是以编写的 Java 代码、框架配置文件、国际化等其他资源文件、JSP 页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程
部署：将Web工程编译后的结果放到服务器的指定目录下并启动服务器
构建的几个环节
- 清理：删除以前的编译结果，为重新编译做好准备
- 编译：将 Java 源程序编译为字节码文件
- 测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性
- 报告：在每一次测试后以标准的格式记录和展示测试结果
- 打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应 jar 包，Web工程对应 war 包
- 安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中
- 部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行
自动化构建：自动完成编译、打包、部署、测试

配置

配置环境变量
- M2_HOME：安装目录
- path：%M2_HOME%\bin

修改配置文件setting.xml

<localRepository> :配置本地仓库地址
<mirrors> ：配置中央仓库

<!-- 配置阿里云作为远程maven仓库 -->
<mirrors>
	<mirror>
      <id>alimaven</id>
      <mirrorOf>central</mirrorOf>
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    </mirror>
</mirrors>

eclipse使用Maven

Maven插件：eclipse内置
Maven插件设置
- installations：指定Maven核心程序的位置
- user settings：指定conf/settings.xml位置，进而获取本地仓库的位置
结合eclipse
- window → Preferences → Maven → Installations → Add → Directory → 增加maven安装目录 → Finish → 选择 → User Setting → Browse → 选择setting.xml路径 → Reindex → 选择本地库路径 → Apple
基本操作
- 创建Maven的java工程
  - New → Maven Project → 勾选选项 → Next → 输入groupid，artifactId，version，选择Packaging为jar → Finish
- 创建Maven的Web工程
  - New → Maven Project → 勾选选项 → Next → 输入groupid，artifactId，version，选择Packaging为war → Finish
- 执行Maven命令
  - Run As → Maven build…(自定义启动命令)

核心概念

约定的目录结构

自定义的资源让框架或工具知道的方式
- 创建配置文件编写路径
- 遵守框架内部约定
- 约定 > 配置 > 编码：意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而 Maven 正是因为指定了特定文件保存的目录能够对我们的 Java 工程进行自动化构建
Maven约定的目录结构
- 根目录：工程名
- src目录：源码
- pom.xml文件：Maven工程核心文件
- main目录：存放主程序
- test目录：存放测试程序
- java目录：存放java源文件
- resource目录：存放框架或其他工具的配置文件
常用Maven命令
- mvn clean ：清理
- mvn compile：编译主程序
- mvn test-compile：编译测试程序
- mvn test：执行测试
- mvn package：打包
- mvn install：安装
- mvn site：生成站点
- 执行或构件过程相关命令必须进入pom.xml所在目录
联网问题
- Maven 的核心程序中仅仅定义了抽象的生命周期，而具体的操作则是由 Maven 的插件来完成的。可是Maven 的插件并不包含在 Maven 的核心程序中，在首次使用时需要联网下载
- 当我们执行Maven命令需要用到某些插件时，Maven首先在本地仓库查找
- 本地仓库默认位置：[系统当前用户的家目录].m2\repository
- 找不到则联网，去中央仓库下载，无法联网则构建失败
- 修改默认本地仓库位置
  - Maven 解压目录下conf\settings.xml中localRepository标签
  - 将标签体内部修改为其他目录地址

POM

含义：Project Object Model：项目对象模型，将 Java 工程的相关信息封装对象作为便于操作和管理的模型。DOM 是 Document Object Model（文档对象模型）的缩写
pom.xml 是 Maven 工程的核心配置，可以说学习 Maven 就是学习 pom.xml 文件中的配置
- <package> //标注项目类型
- <dependencies> //项目运行需要的jar包支持
- <properties> //属性标签,通常用户jar包版本控制
- <build> //全局配置（project build）
  - <plugins> //用于指定使用的插件
    - <plugin> //带动作的jar包有三维数据

坐标

使用三个向量在仓库中唯一定位一个Maven工程，相当于几何中的坐标
- <groupid> ：公司或组织的域名倒序+当前项目名称
- <artifactId> ：当前项目的模块名称
- <version> ：当前模块的版本
通过坐标到仓库中查找jar包
- 将 gav 三个向量连起来
- 以连起来的字符串作为目录结构到仓库中查找
- 我们自己的 Maven 工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

仓库管理

分类
- 本地仓库：为本机上的所有 Maven 工程服务
- 远程仓库
  - 私服：架设在当前局域网环境下，为当前局域网范围内的所有 Maven 工程服务
  - 中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务
  - 中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求
仓库内容
- Maven 的插件
- 我们自己开发的项目的模块
- 第三方框架或工具的 jar 包
- 不管是什么样的 jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖

依赖管理

Maven 中最关键的部分，我们使用 Maven 最主要的就是使用它的依赖管理功能
引入依赖：使用 <dependency> 指定依赖的 jar 包或其他工程的坐标
依赖范围：<scope>有三个值，指明依赖范围

	compile	provided	system	runtime	test
编译阶段	√	√	√	×	×
测试阶段	√	√	√	√	√
运行阶段	√	√	√	√	×
发布阶段	√	×	×	√	×

依赖的传递
- A 依赖 B，B 依赖 C，A 能否使用 C 呢？那要看 B 依赖 C 的范围是不是 compile，如果是则可用，否则不可用
依赖的排除

<!--排除commons-logging.jar -->
<dependency>
 	<groupId>...</groupId>
 	<artifactId>...</artifactId>
 	<version>...</version>
 	<type>jar</type>
 	<scope>compile</scope>
 	<exclusions> 
	 	<exclusion> 
		 	<groupId>commons-logging</groupId> 
		 	<artifactId>commons-logging</artifactId> 
	 	</exclusion> 
 	</exclusions> 
</dependency>

统一管理所依赖 jar 包的版本

对同一个框架的一组 jar 包最好使用相同的版本。为了方便升级框架，可以将 jar 包的版本信息统一提取出来
统一声明版本号

// spring.version是自定义标签
<properties>
	<spring.version>4.1.1.RELEASE</spring.version>
</properties>
<dependencies>
	<dependency>
		<groupId>org.springframework</groupId>
		 <artifactId>spring-core</artifactId>
		<version>${spring.version}</version>
	</dependency>
	……
</dependencies>

依赖的原则：解决 jar 包冲突
- 路径最短者优先
- 路径相同时先声明者优先
- 先后顺序指的是 dependency 标签配置的先后顺序

生命周期

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了
Maven 有三套相互独立的生命周期
- Clean Lifecycle 在进行真正的构建之前进行一些清理工作
- Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等
- Site Lifecycle 生成项目报告，站点，发布站点
它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期
每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段
Clean 生命周期(三个阶段)
- pre-clean 执行一些需要在 clean 之前完成的工作
- clean 移除所有上一次构建生成的文件
- post-clean 执行一些需要在 clean 之后立刻完成的工作
Site 生命周期
- pre-site 执行一些需要在生成站点文档之前完成的工作
- site 生成项目的站点文档
- post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
- site-deploy 将生成的站点文档部署到特定的服务器上
Default 生命周期
- Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中
- process-resources 复制并处理资源文件，至目标目录，准备打包
- compile 编译项目的源代码
- process-test-resources 复制并处理资源文件，至目标测试目录
- test-compile 编译测试源代码
- test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署
- package 接受编译好的代码，打包成可发布的格式，如 JAR
- install 将包安装至本地仓库，以让其它项目依赖
- deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行
生命周期与自动化构建
- 运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行 mvn install 的时候，代码会被编译，测试，打包。这就是 Maven 为什么能够自动执行构建过程的各个环节的原因。此外，Maven 的插件机制是完全依赖 Maven 的生命周期的，因此理解生命周期至关重要

插件和目标

Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的
每个插件都能实现多个功能，每个功能就是一个插件目标，可以将目标看做调用插件功能的命令
Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务

生命周期阶段 | 插件目标 | 插件
-------- | ----- | ----- | -----
compile | compile | Maven-compile-plugin
text-compile | TestCompile | Maven-compile-plugin

继承

由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置，若想要修改某一个信息，那么到各个工程中手动修改无疑是非常不可取的，使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理
创建父工程
- 创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom

<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<packaging>pom</packaging>

创建子工程，引用父工程

<parent>
	<!-- 父工程坐标 -->
	<groupId>...</groupId>
	<artifactId>...</artifactId>
	<version>...</version>
	<!-- 可省略 -->
	<relativePath>从当前目录到父项目的 pom.xml 文件的相对路径</relativePath>
</parent>

在父工程中管理依赖

将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来，用来声明依赖，管理jar包的版本，若不用则子项目会全部继承父项目jar包而非选择继承

<dependencyManagement> 
	<dependencies> 
		<dependency> 
			<groupId>junit</groupId> 
			<artifactId>junit</artifactId>
			 <version>4.9</version> 
			 <scope>test</scope>
		 </dependency>
	</dependencies>
</dependencyManagement>

在子项目中指定需要的依赖，可省略范围和版本号，继承父工程的版本号

<dependencies>
	<dependency> 
		<groupId>junit</groupId> 
		<artifactId>junit</artifactId>
	</dependency>
</dependencies>

聚合

作用：一键安装各个模块工程
配置方式：在一个总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可

<modules>
	<module>../Hello</module>
	<module>../HelloFriend</module>
	<module>../MakeFriends</module>
</modules>

使用方式：在聚合工程的pom.xml上右键 → run as → maven install