1.依赖范围
非compile范围依赖不能传递
2.maven依赖传递
依赖的传递性:如果A—>B,B—>C,那么A—>C。无限层传递。
假设现在:
(1)
A----->B------>C
A自己有依赖了C,如果A现在自己又依赖了C,如果A依赖的C和B传递过来的
C版本不一样那么这时候就会有问题
我在第一个maven工程:
然后在第2个工程中依赖了第一个maven工程同时又定义了:
log4j的版本为1.2.16如图提示依赖冲突:
我们也可以安装一个maven Helper的插件:
(2)
A----->M------>D1.0
A ----->N------>D1.1
2个D的版本不一致那么现在就会有版本问题
2个工程都有log4j的依赖
3.依赖排除
方式一:在声明依赖处排除,适合单处排除。
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
方式二:在远声明依赖处排除,适合多处排除。
<optional>true</optional>
4.maven自己提供的解决冲突的原则
1、最短路径原则:
maven-04-dependency--->maven-03-dependencied2--->maven-03-dependencied---->log4j1.2.12
--->maven-03-commons------>log4j1.2.11
2、最先声明原则(路径一样长)
maven-04-dependency--->maven-03-dependencied2---->log4j1.2.12
--->maven-03-commons------>log4j1.2.11
取最先定义的log4j1.2.12
5.maven的全局变量
自定义变量:
<properties>
<spring.version>4.3.11.RELEASE</spring.version>
</properties>
${变量名} ${spring.version}
内置变量:maven定义好的,可以直接使用
${project.version}
6.maven继承
Maven的聚合:在maven中每一个工程都具有独立构件能力,但是如果工程数量增多,而且工程之间有依赖关系,手动构建很麻烦,几乎不可能手动构建。
所谓聚合,就是把多个模块或项目聚合到一起,创建一个专门的工程进行统一进行管理和构建。
在pom中使用标签来实现,Maven会自动分析模块之间的构建顺序和依赖关系。
1、子POM可以从父POM中继承的元素:
groupId、version、properties、dependencies、build、repositories、pluginRepositories、distributionManagement、dependencyManagement
<finalName>虽然能继承,但是一般都是配置自己的名字。
2、打包方式<packaging>:jar(默认。java工程)、war(web工程)、pom(所有含有子模块的模块,打包方式必须是pom)
父POM的打包方式必须是pom。
3、所有模块或者大多数模块都会使用的配置,在父POM中声明:
properties、groupId、version、dependencies(非compile范围的公共依赖)、build(plugins)
dependencies(非compile范围的公共依赖):junit、servlet、jsp
<dependencies>:声明依赖,实际引入。
<dependencyManagement>:管理依赖。声明依赖,不实际引入,仅仅是声明。
类似的还有:<plugins>和<pluginManagement>