maven的依赖范围和依赖传递

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>