一、Maven概述
1.1 为什么要学习Maven?
-
Maven作为依赖管理工具,能够管理规模庞大jar包。使用Maven后,依赖对应的Jar包能够自动下载、方便、快捷且规范。
-
Maven作为构建管理工具。当我们使用 IDEA 进行开发时,构建是 IDEA 替我们做的。脱离IDEA环境执行构建操作,需要专门工具。
1.2 什么是 Maven?
Maven一款专门为 Java 项目提供构建和依赖管理支持的工具
1.构建:
构建构建指的是使用Java源码、图片、配置文件等生产一个可以在服务器上运行项目的过程
构建的过程包含以下主要环节:
- 清理:删除上一次构建的结果,为下一次构建做好准备
- 编译:Java 源程序编译成 *.class 字节码文件
- 测试:运行提前准备好的测试程序
- 报告:针对刚才测试的结果生成一个全面的信息
- 打包
- Java工程:jar包
- Web工程:war包
- 安装:把一个 Maven 工程经过打包操作生成的 jar 包或 war 包存入 Maven 仓库
- 部署
- 部署 jar 包:把一个 jar 包部署到 Nexus 私服服务器上
- 部署 war 包:借助相关 Maven 插件(例如 cargo),将 war 包部署到 Tomcat 服务器上
2.依赖
如果 A 工程里面用到了 B 工程的类、接口、配置文件等等这样的资源,那么我们就可以说 A 依赖 B。
依赖管理中要解决的具体问题:
- jar 包的下载:使用 Maven 之后,jar 包会从规范的远程仓库下载到本地
- jar 包之间的依赖:通过依赖的传递性自动完成
- jar 包之间的冲突:通过对依赖的配置进行调整,让某些jar包不会被导入
1.3 Maven的工作机制
二、Maven解压和配置
2.1 Maven核心程序解压和配置
-
下载地址:https://maven.apache.org/download.cgi
-
核心程序压缩包:apache-maven-3.8.4-bin.zip,解压到非中文、没有空格的目录
着重关注 Maven 的核心配置文件:conf/settings.xml
1、指定Maven本地仓库:
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
<localRepository>D:\maven-repository</localRepository>
把localRepository标签从注释中拿出来配置本地地址,放jar包
2、配置阿里云提供的镜像仓库:
- 将原有例子注释掉
- 加入我们的配置
<mirror>
<id>nexus-aliyun</id>
<mirrorOf>central</mirrorOf>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
3、配置Maven工程的基础JDK版本
默认配置使用的JDK版本是1.5
<profile>
<id>jdk-1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
2.2 配置环境变量
TIP
配置环境变量的规律:
XXX_HOME 通常指向的是 bin 目录的上一级
PATH 指向的是 bin 目录
- 配置MAVEN-HOME
- 配置PATH
三、使用Maven:命令行环境
3.1 根据坐标创建Maven工程
1.Maven中的坐标
使用三个**『向量』在『Maven的仓库』中唯一的定位到一个『jar』**包。
- groupId:公司或组织的 id
- artifactId:一个项目或者是项目中的一个模块的 id
- version:版本号
2.坐标和仓库中 jar 包的存储路径之间的对应关系
坐标:
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
上面坐标对应的 jar 包在 Maven 本地仓库中的位置:
Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar
3.实验操作:
- 本地创建工作空间,在工作空间目录下打开命令行窗口
- 运行 mvn archetype:generate 命令,根据提示指定坐标
mvn archetype:generate 主命令 插件:目标
- 调整pom.xml修改依赖的junit版本号4.12版本
4.解读pom.xml
<!-- 当前Maven工程的坐标 -->
<groupId>com.atguigu.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前Maven工程的打包方式,可选值有下面三种: -->
<!-- jar:表示这个工程是一个Java工程 -->
<!-- war:表示这个工程是一个Web工程 -->
<!-- pom:表示这个工程是“管理其他工程”的工程 -->
<packaging>jar</packaging>
<name>pro01-maven-java</name>
<url>http://maven.apache.org</url>
<properties>
<!-- 工程构建过程中读取源码时使用的字符集 -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<!-- 当前工程所依赖的jar包 -->
<dependencies>
<!-- 使用dependency配置一个具体的依赖 -->
<dependency>
<!-- 在dependency标签内使用具体的坐标依赖我们需要的一个jar包 -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<!-- scope标签配置依赖的范围 -->
<scope>test</scope>
</dependency>
</dependencies>
5.Maven核心概念:POM
POM:项目对象模型(类比DOM:文档对象模型),是模型化思想的具体体现。pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置,各个配置有什么用。
6.约定的目录结构
- 约定目录结构的意义:
Maven 为了让构建过程能够尽可能自动化完成,所以必须约定目录结构的作用。例如:Maven 执行编译操作,必须先去 Java 源程序目录读取 Java 源代码,然后执行编译,最后把编译结果存放在 target 目录
- 约定大于配置:
Maven 对于目录结构这个问题,没有采用配置的方式,而是基于约定。这样会让我们在开发过程中非常方便。如果每次创建 Maven 工程后,还需要针对各个目录的位置进行详细的配置,那肯定非常麻烦。
目前开发领域的技术发展趋势就是:约定大于配置,配置大于编码
3.2 在Maven工程中编写代码和构建
-
在子目录中分别编写java程序和测试类程序
-
进入pom.xml所在的目录,运行Maven的构建命令。构建相关命令必须进入所操作工程的pom.xml目录
-
清理操作:
mvn clean
删除target目录 -
编译操作:
- 主程序编译:
mvn compile
编译结果存放目录:target/classes - 测试程序编译:
mvn test-compile
编译结果存放目录:target/test-classes
- 主程序编译:
-
测试操作:
mvn test
测试的报告存放的目录:target/surefire-reports -
打包操作:
mvn package
打包的结果——jar 包,存放的目录:target -
安装操作:
mvn install
安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。另外还会将pom.xml转换为XXX.pom文件一起存入本地仓库。
3.3 创建Maven版的Web工程
- 生成Web工程的命令,回到工作空间根目录来操作:
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
生成的Web工程的目录结构:
- 创建Servlet
- main目录下创建java目录
- 在java目录下创建Servlet类所在的包的目录,在包下编写Servlet类
- 在web.xml中注册Servlet
- 在index.jsp页面编写超链接
- 配置对servlet-api.jar包的依赖
对于不知道详细信息的依赖可以到**https://mvnrepository.com/**网站查询。使用关键词搜索,然后在搜索结果列表中选择适合的使用
找到的servlet-api 的依赖信息:加入到pom.xml中
<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
- 执行编译命令:
mvn compile
在target目录下的classes目录下 - 将Web工程打包为war包:
mvn package
在target目录下 - 将war包部署到Tomcat上运行
- 将war包复制到Tomcat/webapps 目录下
- 到bin/startup.bat启动Tomcat,Tomcat会自动解压war包
- 通过浏览器尝试访问:http://localhost:8080/pro02-maven-web/index.jsp
3.4 让 Web 工程依赖 Java 工程
只有web工程依赖Java工程,本质上来说,Java工程会变成jar包,放在Web工程的WEB-INF/lib目录下(war包里有jar包)
- 在pro2-maven-web工程的pom.xml文件中,配置依赖
<!-- 配置对Java工程pro01-maven-java的依赖 -->
<!-- 具体的配置方式:在dependency标签内使用坐标实现依赖 -->
<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
-
编写测试代码
- 补充创建目录:pro02-maven-web**\src\test\java\com\zju\maven**
- 确认web工程依赖了Junit
- 创建测试类
-
执行Maven命令
- 测试命令:
mvn test
测试操作会提前自动编译 - 打包命令:
mvn package
依赖的java工程变成Web工程中WEB-INF/lib目录下的jar包
- 测试命令:
- 查看当前Web工程所依赖的jar包列表:
mvn dependency:list
TIP
[INFO] The following files have been resolved:
[INFO] org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
[INFO] junit:junit:jar:4.12:test
格式是:groupId:artifactId:打包方式:version:依赖的范围,可以用来定位仓库中的Jar包
- 以树形结构查看当前Web工程的依赖信息:
mvn dependency:tree
TIP
[INFO] com.atguigu.maven:pro02-maven-web:war:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- javax.servlet:javax.servlet-api:jar:3.1.0:provided
[INFO] \- com.atguigu.maven:pro01-maven-java:jar:1.0-SNAPSHOT:compile
3.5 依赖的范围
-
标签的位置:dependencies/dependency/scope
-
标签的可选值:compile/test/provided/system/runtime/import
①compile 和 test 对比
main目录(空间) | test目录(空间) | 开发过程(时间) | 部署到服务器(时间) | |
---|---|---|---|---|
compile(默认) | 有效 | 有效 | 有效 | 有效 |
test | 无效 | 有效 | 有效 | 无效 |
②compile 和 provided 对比
main目录(空间) | test目录(空间) | 开发过程(时间) | 部署到服务器(时间) | |
---|---|---|---|---|
compile | 有效 | 有效 | 有效 | 有效 |
provided | 有效 | 有效 | 有效 | 无效 |
③结论
- compile:在项目实际实际运行时真正要用到的jar包
- test:测试过程中用到的jar包,比如junit
- provided:在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包,就是避免和服务器上已有的同类 jar 包产生冲突,同时减轻服务器的负担。说白了就是:“服务器上已经有了,你就别带啦!
3.6 传递依赖性
依赖的原则:
在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围
- B 依赖 C 时使用 compile 范围:可以传递
- B 依赖 C 时使用 test 或 provided 范围:不能传递,所以需要这样的 jar 包时,就必须在需要的地方明确配置依赖才可以。
注意:依赖传递是通过本地仓库的,因此要执行Install使本地仓库有最新的
利用依赖的传递性可以通过仅管理顶层几个jar包依赖达到导入n多jar包的效果
3.7 依赖的排除
1.概念:
当 A 依赖 B,B 依赖 C 而且 C 可以传递到 A 的时候,A 不想要 C,需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。
配置依赖的排除就是为了阻止某些jar包的传递。因为这样的jar包会和其他Jar包冲突。
2.配置方式:
pro02---->pro01----->Sringcore----->commoons-logging
目的:在 pro02-maven-web 工程中配置对 commons-logging 的排除:
<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>
3.8 继承
A工程继承B工程,本质上是A工程的pom.xml继承了B工程中的pom.xml
- 作用
一个大型工程拆分为很多module,对每个module各自维护依赖信息不易管理且整个项目使用的框架版本需要统一。通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确版本的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
- 实际意义
编写一套符合要求、开发各种功能都能正常工作的依赖组合并不容易。如果公司里已经有人总结了成熟的组合方案,那么再开发新项目时,如果不使用原有的积累,而是重新摸索,会浪费大量的时间。为了提高效率,我们可以使用工程继承的机制,让成熟的依赖组合方案能够保留下来。
1.创建父、子工程:
- 创建pro03-maven-parent,修改打包方式
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前工程作为父工程,它要去管理子工程,所以打包方式必须是 pom -->
<packaging>pom</packaging>
打包方式为 pom 的 Maven 工程中不写业务代码,它是专门管理其他 Maven 工程的工程
-
进入 pro03-maven-parent 工程的根目录,然后运行
mvn archetype:generate
命令来创建模块工程 -
(自动生成)查看父工程的pom.xml,modules标签是聚合功能的配置
<modules>
<module>pro04-maven-module</module>
<module>pro05-maven-module</module>
<module>pro06-maven-module</module>
</modules>
- (自动生成)解读子工程pom.xml
<!-- 使用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> -->
2.在父工程中配置依赖的统一管理:
<!-- 使用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>
3.子工程中引用那些被父工程管理的依赖:
关键点:可以省略版本号;可以有选择性引用
<!-- 子工程引用父工程中的依赖信息时,可以把版本号去掉。 -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的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>
4.在父工程中声明定义属性,实现一处修改处处生效
<!-- 通过自定义属性,统一指定Spring的版本 -->
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- 自定义标签,维护Spring版本数据 -->
<zju.spring.version>4.3.6.RELEASE</zju.spring.version>
</properties>
在需要的地方使用${}的形式来引用自定义的属性名:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${zju.spring.version}</version>
</dependency>
3.9 聚合
使用一个“总工程”将各个“模块工程”汇集起来,作为一个整体对应完整的项目。
1.好处:
- 一键执行 Maven 命令:很多构建命令都可以在“总工程”中一键执行。
- 配置聚合之后,各个模块工程会在总工程中展示一个列表,让项目中的各个模块一目了然
2.聚合的配置:
在总工程中配置 modules 即可:
<modules>
<module>pro04-maven-module</module>
<module>pro05-maven-module</module>
<module>pro06-maven-module</module>
</modules>
小心循环依赖问题:
工程间循环依赖:A依赖B;B依赖C;C又依赖A,那么在构建时报错
DANGER
[ERROR] [ERROR] The projects in the reactor contain a cyclic reference:
四、使用Maven:IDEA环境
4.1 创建Maven工程
1 创建父工程
new创建maven项目-----> 配置坐标----->开启自动导入(右边扳手图标)
2.配置Maven信息
每次创建 Project 后都需要设置 Maven 家目录位置,否则 IDEA 将使用内置的 Maven 核心程序(不稳定)并使用默认的本地仓库位置。
3.创建Java模块工程
- 新建maven模块,配置相关依赖
- 编写相关java程序和测试程序
三种方式执行Maven命令:
- 方法一:IDEA右边Maven导航栏,借助图形化界面直接执行
- 方法二:手动输入,输入一些组合指令
# -D 表示后面要附加命令的参数,字母 D 和后面的参数是紧挨着的,中间没有任何其它字符
# maven.test.skip=true 表示在执行命令的过程中跳过测试
mvn clean install -Dmaven.test.skip=true
- 方法三:找到要运行的pom.xml,右键Open in terminal,在命令行输入指令
4.创建Web模块工程
- 先按相同操作创建一个Java模块
- 修改当前模块的pom.xml中打包方式
<packaging>war</packaging>
-
进行Web设定
打开Project Structure---->Feacts------>选中想设置为Web工程的模块
-
借助IDEA生成web.xml xxxmodule\src\main\webapp\WEB-INF\web.xml
生成webapp目录对应war包中WEB-INF目录
- 设置资源目录
- 配置Tomcat
4.2 Maven工程导入
1.git clone结合IDEA从github远程库导入项目
2.来自工程目录
- 解压到IDEA工作空间中,直接用IDEA打开工程
4.3 Maven模块导入
- 复制想要导入的模块到自己的工程目录下
- 在IDEA中执行导入
- Projet Stucture----->modules----->import Module----->选中粘贴的模块----->选择以Maven形式
- 导入Web工程得重新进行Web设定
- 修改导入module的pom.xml文件,改成自己project的父工程坐标
web工程打成war包后,pom.xml中的依赖会统一放在war包webapp目录下的WEBINF下的lib目录中
五、其他核心概念
5.1生命周期
为了让构建过程自动化完成,Maven 设定了三个生命周期,生命周期中的每一个环节对应构建过程中的一个操作。
- 在任何一个生命周期内部,执行任何一个具体环节的操作,都是从本周期最初的位置开始执行,直到指定的地方。(本节记住这句话就行了,其他的都不需要记)
5.2 插件和目标
1.插件
Maven 的核心程序仅仅负责宏观调度,不做具体工作。具体工作都是由 Maven 插件完成的。例如:编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
2.目标
一个插件可以对应多个目标,而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节,这两个环节对应 compile 和 test-compile 两个目标,而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
5.3 仓库
- 本地仓库:在当前电脑上,为电脑上所有 Maven 工程服务
- 远程仓库:需要联网
- 局域网:我们自己搭建的 Maven 私服,例如使用 Nexus 技术。
- Internet
- 中央仓库
- 镜像仓库:内容和中央仓库保持一致,但是能够分担中央仓库的负载,同时让用户能够就近访问提高下载速度,例如:Nexus aliyun
建议:不要中央仓库和阿里云镜像混用,否则 jar 包来源不纯,彼此冲突。
专门搜索 Maven 依赖信息的网站:https://mvnrepository.com/
置开始执行,直到指定的地方。(本节记住这句话就行了,其他的都不需要记)**
[外链图片转存中…(img-uLXdPpSB-1648617732737)]
5.2 插件和目标
1.插件
Maven 的核心程序仅仅负责宏观调度,不做具体工作。具体工作都是由 Maven 插件完成的。例如:编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
2.目标
一个插件可以对应多个目标,而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节,这两个环节对应 compile 和 test-compile 两个目标,而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
5.3 仓库
- 本地仓库:在当前电脑上,为电脑上所有 Maven 工程服务
- 远程仓库:需要联网
- 局域网:我们自己搭建的 Maven 私服,例如使用 Nexus 技术。
- Internet
- 中央仓库
- 镜像仓库:内容和中央仓库保持一致,但是能够分担中央仓库的负载,同时让用户能够就近访问提高下载速度,例如:Nexus aliyun
建议:不要中央仓库和阿里云镜像混用,否则 jar 包来源不纯,彼此冲突。
专门搜索 Maven 依赖信息的网站:https://mvnrepository.com/