marven的坐标

Maven世界拥有大量构件，我们需要找一个用来唯一标识一个构件的统一规范
拥有了统一规范，就可以把查找工作交给机器
例如项目所需的Junit依赖，我们只需在pom.xml文件中添加坐标依赖即可，marven会帮我们从仓库中查找

• groupId：定义当前Maven组织名称
• artifactId：定义实际项目名称
• version：定义当前项目的当前版本
• packaging：项目的打包方式，最为常见的jar和war两种

marven的依赖

就是对项目中jar 包的管理。可以在pom文件中定义jar包的GAV坐标，管理依赖。
依赖声明主要包含如下元素：

<!--添加依赖配置-->
      <dependencies>
          <!--项目要使用到junit的jar包，所以在这里添加junit的jar包的依赖-->
          <dependency>
              <groupId>junit</groupId>
              <artifactId>junit</artifactId>
              <version>4.9</version>
              <scope>test</scope>
          </dependency>
     </dependencies>

依赖的范围

依赖范围scope用来控制依赖和编译，测试，运行的classpath的关系. 主要的是三种依赖关系如下：

1.compile： 默认编译依赖范围。对于编译，测试，运行三种classpath都有效

2.test：测试依赖范围。只对于测试classpath有效

3.provided：已提供依赖范围。对于编译，测试的classpath都有效，但对于运行无效。因为由容器已经提供，例如servlet-api

4.runtime:运行时提供。例如:jdbc驱动

直接依赖和间接依赖

如果B中使用A，C中使用B，则称A是B的直接依赖，而称A是C的间接依赖。

C->B->A

C直接依赖B

C间接依赖A

依赖范围对传递依赖的影响

左边第一列表示第一直接依赖范围

上面第一行表示第二直接依赖范围

那什么是第一依赖与第二依赖呢？
假设有这么几个maven项目。A—>B—->C—->D—->E—->F 其中箭头表示引用依赖。
站在A的角度上来说。A和B是第一依赖。B和C是第二依赖。你站在B的角度来说。B和C是第一依赖，C和D是第二依赖。

中间的交叉单元格表示传递性依赖范围。

总结：

• 当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。
• 当第二直接依赖的范围是test的时候，依赖不会得以传递。
• 当第二依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范- 围同样为 provided；
• 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为runtime；
• 如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准（就近原则）
• 如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准（就近原则）

可选依赖

<exclusions>
    <exclusion>
        <groupId>cn.itcast.maven</groupId>
        <artifactId>maven-first</artifactId>
    </exclusion>
</exclusions>