Java – Maven 基本使用教程
简介
Maven 是一款为 Java 项目构建管理、依赖管理的工具(软件),使用 Maven 可以自动化构建测试、打包和发布项目,大大提高了开发效率和质量。总结: Maven 就是一个软件,掌握软件安装、配置、以及基本功能(项目构建、依赖管理) 使用就是本课程的主要目标!
安装和配置
增加运行环境变量
在环境变量中增加以下变量
MAVEN_HOME: maven 的解压路经
Path: %MAVEN_HOME%\bin
通过调用maven测试命令
mvn -v
更改仓库存储地址
maven 默认会在 ${user.home}/.m2/repository 中创建仓库文件夹,但是通常都在C盘,这样会比较占用C盘空间,因此我们可以找到以下的标签更改仓库存储的位置
文件夹会自动创建
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<!-- conf/settings.xml 55行 -->
<localRepository>D:\repository</localRepository>
修改国内镜像地址
修改后可以让下载依赖变得更快
<!--在mirrors节点(标签)下添加中央仓库镜像 160行附近-->
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
选用编译jdk版本
修改maven构建项目时要使用的jdk版本
<!--在profiles节点(标签)下添加jdk编译版本 268行附近-->
<profile>
<id>jdk-17</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>17</jdk>
</activation>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.compilerVersion>17</maven.compiler.compilerVersion>
</properties>
</profile>
Maven 的 GAVP 属性
GAVP 属性指的是 Maven 项目中的 GroupID、ArtifactID、Version、Packaging
GroupID : com.{公司/BU }.业务线.[子业务线],最多 4 级。
说明:{公司/BU} 例如:alibaba/taobao/tmall/aliexpress 等 BU 一级;子业务线可选。
正例:com.taobao.tddl 或 com.alibaba.sourcing.multilang com.atguigu.java
ArtifactID 格式:产品线名-模块名。语义不重复不遗漏,先到仓库中心去查证一下。
正例:tc-client / uic-api / tair-tool / bookstore
Version版本号格式推荐:主版本号.次版本号.修订号 1.0.0
1) 主版本号:当做了不兼容的 API 修改,或者增加了能改变产品方向的新功能。
2) 次版本号:当做了向下兼容的功能性新增(新增类、接口等)。
3) 修订号:修复 bug,没有修改方法签名的功能加强,保持 API 兼容性。
例如: 初始→1.0.0 修改bug → 1.0.1 功能调整 → 1.1.1等
Packaging定义规则:
指示将项目打包为什么类型的文件,idea根据packaging值,识别maven项目类型!
packaging 属性为 jar(默认值),代表普通的Java工程,打包以后是.jar结尾的文件。
packaging 属性为 war,代表Java的web工程,打包以后.war结尾的文件。
packaging 属性为 pom,代表不会打包,用来做继承的父工程。
构建Maven工程
构建JavaEE工程
构建JavaWeb工程
要构建JavaWeb工程,只需要先构建一个普通的JavaEE工程,再在pom.xml文件中设置
<packaging>war</packaging>
此后在src 文件夹下新建 webapp/WEB-INF/web.xml 文件和目录既可。
使用插件转为Web工程
使用插件 JBLJavaToWeb 后就可以直接让 JavaEE 工程转为JavaWeb工程
Maven 工程项目结构说明
|-- pom.xml # Maven 项目管理文件
|-- src
|-- main # 项目主要代码
| |-- java # Java 源代码目录
| | `-- com/example/myapp # 开发者代码主目录
| | |-- controller # 存放 Controller 层代码的目录
| | |-- service # 存放 Service 层代码的目录
| | |-- dao # 存放 DAO 层代码的目录
| | `-- model # 存放数据模型的目录
| |-- resources # 资源目录,存放配置文件、静态资源等
| | |-- log4j.properties # 日志配置文件
| | |-- spring-mybatis.xml # Spring Mybatis 配置文件
| | `-- static # 存放静态资源的目录
| | |-- css # 存放 CSS 文件的目录
| | |-- js # 存放 JavaScript 文件的目录
| | `-- images # 存放图片资源的目录
| `-- webapp # 存放 WEB 相关配置和资源
| |-- WEB-INF # 存放 WEB 应用配置文件
| | |-- web.xml # Web 应用的部署描述文件
| | `-- classes # 存放编译后的 class 文件
| `-- index.html # Web 应用入口页面
`-- test # 项目测试代码
|-- java # 单元测试目录
`-- resources # 测试资源目录
pom.xml:Maven 项目管理文件,用于描述项目的依赖和构建配置等信息。
src/main/java:存放项目的 Java 源代码。
src/main/resources:存放项目的资源文件,如配置文件、静态资源等。
src/main/webapp/WEB-INF:存放 Web 应用的配置文件。
src/main/webapp/index.html:Web 应用的入口页面。
src/test/java:存放项目的测试代码。
src/test/resources:存放测试相关的资源文件,如测试配置文件等。
Maven 的依赖管理
基本的依赖管理
<!--
通过编写依赖jar包的gav必要属性,引入第三方依赖!
scope属性是可选的,可以指定依赖生效范围!
依赖信息查询方式:
1. maven仓库信息官网 https://mvnrepository.com/
2. mavensearch插件搜索
-->
<dependencies>
<!-- 引入具体的依赖包 -->
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<!--
生效范围
- compile :main目录 test目录 打包打包 [默认]
- provided:main目录 test目录 如,Servlet,开发时需要,实际运行时有Tomcat
- runtime: 打包运行 如,MySQL,开发时不会用(用反射),运行时就需要
- test: test目录 如,junit,只在测试时使用
-->
<scope>runtime</scope>
</dependency>
</dependencies>
依赖的作用范围 scoped 说明
依赖范围 | 描述 |
---|---|
compile | 编译依赖范围,scope 元素的缺省值。使用此依赖范围的 Maven 依赖,对于三种 classpath 均有效,即该 Maven 依赖在上述三种 classpath 均会被引入。例如,log4j 在编译、测试、运行过程都是必须的。Maven 默认值 |
test | 测试依赖范围。使用此依赖范围的 Maven 依赖,只对测试 classpath 有效。例如,Junit 依赖只有在测试阶段才需要。 |
provided | 已提供依赖范围。使用此依赖范围的 Maven 依赖,只对编译 classpath 和测试 classpath 有效。例如,servlet-api 依赖对于编译、测试阶段而言是需要的,但是运行阶段,由于外部容器已经提供,故不需要 Maven 重复引入该依赖。 |
runtime | 运行时依赖范围。使用此依赖范围的 Maven 依赖,只对测试 classpath、运行 classpath 有效。例如,JDBC 驱动实现依赖,其在编译时只需 JDK 提供的 JDBC 接口即可,只有测试、运行阶段才需要实现了 JDBC 接口的驱动。 |
system | 系统依赖范围,其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖,通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低,一般不推荐使用。 |
import | 导入依赖范围,该依赖范围只能与 dependencyManagement 元素配合使用,其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中。 |
依赖版本的维护
当一个项目开发比较久后,我们可能会引入非常多的jar包,这样的版本非常杂,可能jar包与jar包之间还有互相引用,这时jar包和jar包的版本是有关系的,如果版本都写在dependency中,万一某个jar包的版本改了,其它的引用jar包也得改,所以我们可以把版本信息提取出来放到公共地方
<!--声明版本-->
<properties>
<!--命名随便,内部制定版本号即可!-->
<junit.version>4.11</junit.version>
<!-- 也可以通过 maven规定的固定的key,配置maven的参数!如下配置编码格式!-->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<!--引用properties声明版本 -->
<version>${junit.version}</version>
</dependency>
</dependencies>
依赖传递与冲突
依赖传递指的是当一个模块或库 A 依赖于另一个模块或库 B,而 B 又依赖于模块或库 C,那么 A 会间接依赖于 C。这种依赖传递结构可以形成一个依赖树。当我们引入一个库或框架时,构建工具(如 Maven、Gradle)会自动解析和加载其所有的直接和间接依赖,确保这些依赖都可用。
依赖传递的作用是:
- 减少重复依赖:当多个项目依赖同一个库时,Maven 可以自动下载并且只下载一次该库。这样可以减少项目的构建时间和磁盘空间。
- 自动管理依赖: Maven 可以自动管理依赖项,使用依赖传递,简化了依赖项的管理,使项目构建更加可靠和一致。
- 确保依赖版本正确性:通过依赖传递的依赖,之间都不会存在版本兼容性问题,确实依赖的版本正确性!
依赖传递演示:
项目中,需要导入jackson相关的依赖,通过之前导入经验,jackson需要导入三个依赖,分别为:
通过查看网站介绍的依赖传递特性:data-bind中,依赖其他两个依赖
最佳导入:直接可以导入data-bind,自动依赖传递需要的依赖
<!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.15.0</version>
</dependency>
依赖冲突演示:
当直接引用或者间接引用出现了相同的jar包! 这时呢,一个项目就会出现相同的重复jar包,这就算作冲突!依赖冲突避免出现重复依赖,并且终止依赖传递!
maven自动解决依赖冲突问题能力,会按照自己的原则,进行重复依赖选择。同时也提供了手动解决的冲突的方式,不过不推荐!
解决依赖冲突(如何选择重复依赖)方式:
- 自动选择原则
-
短路优先原则(第一原则)
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
-
依赖路径长度相同情况下,则“先声明优先”(第二原则)
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
在<depencies></depencies>中,先声明的,路径相同,会优先选择!
-
- 手动配置依赖排除
- 通过配置手动排除该依赖的传递
-
<dependency> <groupId>com.atguigu.maven</groupId> <artifactId>pro01-maven-java</artifactId> <version>1.0-SNAPSHOT</version> <scope>compile</scope> <!-- 使用excludes标签配置依赖的排除 --> <exclusions> <!-- 在exclude标签中配置一个具体的排除 --> <exclusion> <!-- 指定要排除的依赖的坐标(不需要写version) --> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency>
依赖导入失败场景和解决方案
在使用 Maven 构建项目时,可能会发生依赖项下载错误的情况,主要原因有以下几种:
- 下载依赖时出现网络故障或仓库服务器宕机等原因,导致无法连接至 Maven 仓库,从而无法下载依赖。
- 依赖项的版本号或配置文件中的版本号错误,或者依赖项没有正确定义,导致 Maven 下载的依赖项与实际需要的不一致,从而引发错误。
- 本地 Maven 仓库或缓存被污染或损坏,导致 Maven 无法正确地使用现有的依赖项,并且也无法重新下载!
解决方案:
-
检查网络连接和 Maven 仓库服务器状态。
-
确保依赖项的版本号与项目对应的版本号匹配,并检查 POM 文件中的依赖项是否正确。
-
清除本地 Maven 仓库缓存(lastUpdated 文件),因为只要存在lastupdated缓存文件,刷新也不会重新下载。本地仓库中,根据依赖的gav属性依次向下查找文件夹,最终删除内部的文件,刷新重新下载即可!
例如: pom.xml依赖
<dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.8</version> </dependency>
文件:脚本使用:
-
@echo off rem 这里写你的仓库路径 set REPOSITORY_PATH=D:\repository rem 正在搜索... for /f "delims=" %%i in ('dir /b /s "%REPOSITORY_PATH%\*lastUpdated*"') do ( del /s /q %%i ) rem 搜索完毕 pause
扩展构建管理和插件配置
构建概念:
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程,在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
主动触发场景:
- 重新编译 : 编译不充分, 部分文件没有被编译!
- 打包 : 独立部署到外部服务器软件,打包部署
- 部署本地或者私服仓库 : maven工程加入到本地或者私服仓库,供其他工程使用
命令方式构建:
语法: mvn 构建命令 构建命令....
命令 | 描述 |
---|---|
mvn clean | 清理编译或打包后的项目结构,删除target文件夹 |
mvn compile | 编译项目,生成target文件 |
mvn test | 执行测试源码 (测试) |
mvn site | 生成一个项目依赖信息的展示页面 |
mvn package | 打包项目,生成war / jar 文件 |
mvn install | 打包后上传到maven本地仓库(本地部署) |
mvn deploy | 只打包,上传到maven私服仓库(私服部署) |
可视化方式构建:
主动触发场景:
- 重新编译 : 编译不充分, 部分文件没有被编译!
- 打包 : 独立部署到外部服务器软件,打包部署
- 部署本地或者私服仓库 : maven工程加入到本地或者私服仓库,供其他工程使用
命令方式构建:
语法: mvn 构建命令 构建命令....
命令 | 描述 |
---|---|
mvn clean | 清理编译或打包后的项目结构,删除target文件夹 |
mvn compile | 编译项目,生成target文件 |
mvn test | 执行测试源码 (测试) |
mvn site | 生成一个项目依赖信息的展示页面 |
mvn package | 打包项目,生成war / jar 文件 |
mvn install | 打包后上传到maven本地仓库(本地部署) |
mvn deploy | 只打包,上传到maven私服仓库(私服部署) |
可视化方式构建:
打包: mvn clean package
重新编译: mvn clean compile
本地部署: mvn clean install
周期,命令和插件:
周期→包含若干命令→包含若干插件!
使用周期命令构建,简化构建过程!
最终进行构建的是插件!
插件配置:
<build>
<!-- jdk17 和 war包版本插件不匹配 -->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>
</build>
工程构建之指定打包文件名
在Maven 中,默认对打包出来的jar文件名由 ArtifactId + version 作为组合,如果我们希望通过自定义打包名称,我们可以通过以下标签设置
<build>
<finalName>定义打包名称</finalName>
</build>
工程构建之指定资源文件打包
在Maven中,会默认提供一个叫“resources”文件夹用于存放项目中的各种资源文件,在打包时,Maven会对指定位置的资源文件进行打包,但是对于"Java"文件夹中,只会识别出 .java 文件并进行打包,若在 java 文件中存入其它资源文件时,Maven会默认忽略,要使Maven也识别 java 文件夹中的资源文件,我们可以让Maven指定
<build>
<!--设置要打包的资源位置-->
<resources>
<resource>
<!--设置资源所在目录-->
<directory>src/main/java</directory>
<includes>
<!--设置包含的资源类型-->
<include>**/*.xml</include>
</includes>
</resource>
</resources>
</build>
Maven的继承特性
Maven 继承是指在 Maven 的项目中,让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息,简化项目的管理和维护工作。
继承作用
作用:在父工程中统一管理项目中的依赖信息,进行统一版本管理!
它的背景是:
-
- 对一个比较大型的项目进行了模块拆分。
- 一个 project 下面,创建了很多个 module。
- 每一个 module 都需要配置自己的依赖信息。 它背后的需求是:
- 多个模块要使用同一个框架,它们应该是同一个版本,所以整个项目中使用的框架版本需要统一管理。
- 使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试,最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。 通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
子工程需要使用父工程时可以做以下配置:
父工程
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前工程作为父工程,它要去管理子工程,所以打包方式必须是 pom -->
<packaging>pom</packaging>
子工程
<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
<!-- 父工程的坐标 -->
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致,那么可以省略 -->
<!-- <groupId>com.atguigu.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->
父工程版本统一管理
有一种情况,如果父工程加入了依赖,那么默认情况下,子工程都会统一依赖父工程的依赖,但是如果我希望不是所有的子工程都全部依赖父工程的坐标,那么可以使用 dependencyManagement 标签
<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>4.0.0.RELEASE</version>
</dependency>
</dependencies>
</dependencyManagement>
在父工程中加入 dependencyManagement 说明,父工程为子工程准备了某些版本的依赖,但没有要求子工程都依赖上,而是提供了一种选择,当子工程中刚好需要依赖某个坐标时,而父工程的dependencyManagement 中刚好又有,那么子工程可以不用设置 version 版本号,即会引用父工程在 dependencyManagement 中声明的坐标版本。
<!-- 子工程引用父工程中的依赖信息时,可以把版本号去掉。 -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
</dependency>
</dependencies>
Maven 的聚合特性
聚合特性是指,
1.当父工程中操作一些工作时,子工程也会一起带着操作,如清理父工程时,其下的所有子工程都会一同被清理。
2.当新增一个新的子工程时,父工程也会自动的把这个新的子工程加到其下中。
3.若想希望子工程作继承父工程,而不希望父工程的操作影响到子工程时,可以在父工程中删除子工程的modules 标签
<project>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<modules>
<module>child-project1</module>
<module>child-project2</module>
<module>child-project3</module>
<!-- 删除后,父工程做清理等操作不会把child-project3一起处理 -->
</modules>
</project>
使用自定义的Maven插件版本
Maven 插件是每一个Maven工程中必须存有的,但有时候一些打包规则不兼容,我们可以自定义Maven使用的版本,如当使用jdk17去打包war包时,有可能会出现打包错误,这是因为Maven版本不兼容的原因。
<!-- 统一更新子工程打包插件-->
<build>
<!-- jdk17 和 war包版本插件不匹配 -->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>
</build>
Maven 私服
Nexus下载安装
下载地址:https://help.sonatype.com/repomanager3/product-information/download
解压,以管理员身份打开CMD,进入bin目录下,执行./nexus /run命令启动
访问 Nexus 首页
首页地址:http://localhost:8081/,8081为默认端口号
仓库类型 | 说明 |
---|---|
proxy | 某个远程仓库的代理 |
group | 存放:通过 Nexus 获取的第三方 jar 包 |
hosted | 存放:本团队其他开发人员部署到 Nexus 的 jar 包 |
仓库名称 | 说明 |
---|---|
maven-central | Nexus 对 Maven 中央仓库的代理 |
maven-public | Nexus 默认创建,供开发人员下载使用的组仓库 |
maven-releases | Nexus 默认创建,供开发人员部署自己 jar 包的宿主仓库 要求 releases 版本 |
maven-snapshots | Nexus 默认创建,供开发人员部署自己 jar 包的宿主仓库 要求 snapshots 版本 |
通过 Nexus 下载 jar 包
修改本地maven的核心配置文件settings.xml,设置新的本地仓库地址
<!-- 配置一个新的 Maven 本地仓库 -->
<localRepository>D:/maven-repository-new</localRepository>
把我们原来配置阿里云仓库地址的 mirror 标签改成下面这样:
<mirror>
<id>nexus-mine</id>
<mirrorOf>central</mirrorOf>
<name>Nexus mine</name>
<url>http://localhost:8081/repository/maven-public/</url>
</mirror>
果我们在前面允许了匿名访问,到这里就够了。但如果我们禁用了匿名访问,那么接下来我们还要继续配置 settings.xml:
<server>
<id>nexus-mine</id>
<username>admin</username>
<password>atguigu</password>
</server>
这里需要格外注意:server 标签内的 id 标签值必须和 mirror 标签中的 id 值一样。
找一个用到框架的 Maven 工程,执行命令:
mvn clean compile
将 jar 包部署到 Nexus
maven工程中配置:
<distributionManagement>
<snapshotRepository>
<id>nexus-mine</id>
<name>Nexus Snapshot</name>
<url>http://localhost:8081/repository/maven-snapshots/</url>
</snapshotRepository>
</distributionManagement>
注意:这里 snapshotRepository 的 id 标签必须和 settings.xml 中指定的 mirror 标签的 id 属性一致。
执行部署命令:
mvn deploy
引用别人部署的 jar 包
maven工程中配置:
<repositories>
<repository>
<id>nexus-mine</id>
<name>nexus-mine</name>
<url>http://localhost:8081/repository/maven-snapshots/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
共有 0 条评论