活动地址:CSDN21天学习挑战赛
Maven作为依赖管理工具,能够管理规模庞大jar包。使用Maven后,依赖对应的Jar包能够自动下载、方便、快捷且规范。
Maven作为构建管理工具。当我们使用 IDEA 进行开发时,构建是 IDEA 替我们做的。脱离IDEA环境执行构建操作,需要专门工具。
构建构建指的是使用Java源码、图片、配置文件等生产一个可以在服务器上运行项目的过程
构建的过程包含以下主要环节:
如果 A 工程里面用到了 B 工程的类、接口、配置文件等等这样的资源,那么我们就可以说 A 依赖 B。
依赖管理中要解决的具体问题:

着重关注 Maven 的核心配置文件:conf/settings.xml
D:\maven-repository
把localRepository标签从注释中拿出来配置本地地址,放jar包
nexus-aliyun
central
Nexus aliyun
http://maven.aliyun.com/nexus/content/groups/public
jdk-1.8
true
1.8
1.8
1.8
1.8
TIP
配置环境变量的规律:
XXX_HOME 通常指向的是 bin 目录的上一级
PATH 指向的是 bin 目录
使用三个**『向量』在『Maven的仓库』中唯一的定位到一个『jar』**包。
坐标:
javax.servlet
servlet-api
2.5
上面坐标对应的 jar 包在 Maven 本地仓库中的位置:
Maven本地仓库根目录\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar
mvn archetype:generate 主命令 插件:目标
com.atguigu.maven
pro01-maven-java
1.0-SNAPSHOT
jar
pro01-maven-java
http://maven.apache.org
UTF-8
junit
junit
4.12
test
POM:项目对象模型(类比DOM:文档对象模型),是模型化思想的具体体现。pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置,各个配置有什么用。
Maven 为了让构建过程能够尽可能自动化完成,所以必须约定目录结构的作用。例如:Maven 执行编译操作,必须先去 Java 源程序目录读取 Java 源代码,然后执行编译,最后把编译结果存放在 target 目录
Maven 对于目录结构这个问题,没有采用配置的方式,而是基于约定。这样会让我们在开发过程中非常方便。如果每次创建 Maven 工程后,还需要针对各个目录的位置进行详细的配置,那肯定非常麻烦。
目前开发领域的技术发展趋势就是:约定大于配置,配置大于编码
在子目录中分别编写java程序和测试类程序
进入pom.xml所在的目录,运行Maven的构建命令。构建相关命令必须进入所操作工程的pom.xml目录
清理操作:mvn clean 删除target目录
编译操作:
测试操作:mvn test 测试的报告存放的目录:target/surefire-reports
打包操作:mvn package 打包的结果——jar 包,存放的目录:target
安装操作:mvn install
安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。另外还会将pom.xml转换为XXX.pom文件一起存入本地仓库。
mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DarchetypeVersion=1.4
生成的Web工程的目录结构:
对于不知道详细信息的依赖可以到**https://mvnrepository.com/**网站查询。使用关键词搜索,然后在搜索结果列表中选择适合的使用
找到的servlet-api 的依赖信息:加入到pom.xml中
javax.servlet
javax.servlet-api
3.1.0
provided
只有web工程依赖Java工程,本质上来说,Java工程会变成jar包,放在Web工程的WEB-INF/lib目录下(war包里有jar包)
com.atguigu.maven
pro01-maven-java
1.0-SNAPSHOT
compile
编写测试代码
执行Maven命令
查看当前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包
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
标签的位置:dependencies/dependency/scope
标签的可选值:compile/test/provided/system/runtime/import
| main目录(空间) | test目录(空间) | 开发过程(时间) | 部署到服务器(时间) | |
|---|---|---|---|---|
| compile | 有效 | 有效 | 有效 | 有效 |
| test | 无效 | 有效 | 有效 | 无效 |
| main目录(空间) | test目录(空间) | 开发过程(时间) | 部署到服务器(时间) | |
|---|---|---|---|---|
| compile | 有效 | 有效 | 有效 | 有效 |
| provided | 有效 | 有效 | 有效 | 无效 |
在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围
注意:依赖传递是通过本地仓库的,因此要执行Install使本地仓库有最新的
利用依赖的传递性可以通过仅管理顶层几个jar包依赖达到导入n多jar包的效果
当 A 依赖 B,B 依赖 C 而且 C 可以传递到 A 的时候,A 不想要 C,需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。
配置依赖的排除就是为了阻止某些jar包的传递。因为这样的jar包会和其他Jar包冲突。
pro02---->pro01----->Sringcore----->commoons-logging
目的:在 pro02-maven-web 工程中配置对 commons-logging 的排除:
com.atguigu.maven
pro01-maven-java
1.0-SNAPSHOT
compile
commons-logging
commons-logging
A工程继承B工程,本质上是A工程的pom.xml继承了B工程中的pom.xml
一个大型工程拆分为很多module,对每个module各自维护依赖信息不易管理且整个项目使用的框架版本需要统一。通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确版本的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
编写一套符合要求、开发各种功能都能正常工作的依赖组合并不容易。如果公司里已经有人总结了成熟的组合方案,那么再开发新项目时,如果不使用原有的积累,而是重新摸索,会浪费大量的时间。为了提高效率,我们可以使用工程继承的机制,让成熟的依赖组合方案能够保留下来。
com.atguigu.maven
pro03-maven-parent
1.0-SNAPSHOT
pom
打包方式为 pom 的 Maven 工程中不写业务代码,它是专门管理其他 Maven 工程的工程
进入 pro03-maven-parent 工程的根目录,然后运行mvn archetype:generate命令来创建模块工程
(自动生成)查看父工程的pom.xml,modules标签是聚合功能的配置
pro04-maven-module
pro05-maven-module
pro06-maven-module
com.atguigu.maven
pro03-maven-parent
1.0-SNAPSHOT
pro04-maven-module
org.springframework
spring-core
4.0.0.RELEASE
org.springframework
spring-beans
4.0.0.RELEASE
org.springframework
spring-context
4.0.0.RELEASE
org.springframework
spring-expression
4.0.0.RELEASE
org.springframework
spring-aop
4.0.0.RELEASE
关键点:可以省略版本号;可以有选择性引用
org.springframework
spring-core
org.springframework
spring-beans
org.springframework
spring-context
org.springframework
spring-expression
org.springframework
spring-aop
UTF-8
4.3.6.RELEASE
在需要的地方使用${}的形式来引用自定义的属性名:
org.springframework
spring-core
${zju.spring.version}
使用一个“总工程”将各个“模块工程”汇集起来,作为一个整体对应完整的项目。
在总工程中配置 modules 即可:
pro04-maven-module
pro05-maven-module
pro06-maven-module
小心循环依赖问题:
工程间循环依赖:A依赖B;B依赖C;C又依赖A,那么在构建时报错
DANGER
[ERROR] [ERROR] The projects in the reactor contain a cyclic reference:
new创建maven项目-----> 配置坐标----->开启自动导入(右边扳手图标)

每次创建 Project 后都需要设置 Maven 家目录位置,否则 IDEA 将使用内置的 Maven 核心程序(不稳定)并使用默认的本地仓库位置。
# -D 表示后面要附加命令的参数,字母 D 和后面的参数是紧挨着的,中间没有任何其它字符
# maven.test.skip=true 表示在执行命令的过程中跳过测试
mvn clean install -Dmaven.test.skip=true
war
打开Project Structure---->Feacts------>选中想设置为Web工程的模块
生成webapp目录对应war包中WEB-INF目录
为了让构建过程自动化完成,Maven 设定了三个生命周期,生命周期中的每一个环节对应构建过程中的一个操作。
Maven 的核心程序仅仅负责宏观调度,不做具体工作。具体工作都是由 Maven 插件完成的。例如:编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
一个插件可以对应多个目标,而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节,这两个环节对应 compile 和 test-compile 两个目标,而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
建议:不要中央仓库和阿里云镜像混用,否则 jar 包来源不纯,彼此冲突。
专门搜索 Maven 依赖信息的网站:https://mvnrepository.com/
置开始执行,直到指定的地方。(本节记住这句话就行了,其他的都不需要记)**
Maven 的核心程序仅仅负责宏观调度,不做具体工作。具体工作都是由 Maven 插件完成的。例如:编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
一个插件可以对应多个目标,而每一个目标都和生命周期中的某一个环节对应。
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节,这两个环节对应 compile 和 test-compile 两个目标,而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
建议:不要中央仓库和阿里云镜像混用,否则 jar 包来源不纯,彼此冲突。
专门搜索 Maven 依赖信息的网站:https://mvnrepository.com/