Maven的依赖的坐标和坐标的传递

Maven的依赖的坐标和坐标的传递

坐标:查找某个依赖,通过这个依赖(jar)的groupId , artifactId ,version

依赖的传递:

一个项目开发过程:
编码–>编译–>测试–>运行–>打包

依赖的范围:
在dependency 的标签添加一个子标签 设置依赖的范围:

• compile：编译范围，指 A 在编译时依赖 B，此范围为默认依赖范围。编译范围的依赖会用在
  编译、测试、运行，由于运行时需要所以编译范围的依赖会被打包。

• provided：provided 依赖只有在当 JDK 或者一个容器已提供该依赖之后才使用， provided
  依赖在编译和测试时需要，在运行时不需要，比如：servlet api 被 tomcat 容器提供。

• runtime：runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如：jdbc 的驱动包。由于运行时需要所以
  runtime 范围的依赖会被打包。

• test：test 范围依赖 在编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用， 比如：junit。由于运行时不需要所以
  test范围依赖不会被打包。

• system：system 范围依赖与 provided 类似，但是你必须显式的提供一个对于本地系统中 JAR 文件的路径，需要指定
  systemPath 磁盘路径，system依赖不推荐使用。
  
  在 maven-web 工程中测试各各 scop。
  测试总结：

• 默认引入 的 jar 包 ------- compile 【默认范围 可以不写】（编译、测试、运行 都有效 ）

• servlet-api 、jsp-api ------- provided （编译、测试 有效， 运行时无效 防止和 tomcat 下
  jar 冲突）

• jdbc 驱动 jar 包 ---- runtime （测试、运行 有效 ） junit ----- test （测试有效）

• 依赖范围由强到弱的顺序是：compile>provided>runtime>test

排除依赖传递
当我A模块依赖于B模块,而B模块依赖于C模块,那么A模块也就间接的依赖于C模块,这种依赖主要是基于complie范围(编译范围)的依赖.但是对于scope是test,那不会进行依赖的传递.
有的时候为了避免这种间接的依赖,我们可以使用来排除依赖.

• 如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准（就近原则）
• 如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准（就近原则)

版本归类
通常在项目中，我们会同时依赖同一个构件的不同模块，如 spring-orm-3.2.0，spring-context-3.2.0，且多个模块版本相同，为了维护和升级方便，我们可以对其同一管理，这时可以使用到 Maven 属性，类似于变量的概念。

<properties>
	<!--版本归并 :  
	相当于在java中定义一个变量  springframework.version=3.2.0.RELEASE  -->
      <springframework.version>3.2.0.RELEASE</springframework.version>
  </properties>
  
  <dependencies>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-orm</artifactId>
          <!--用${标签名} 取值-->
          <version>${springframework.version}</version>
     </dependency>
     <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring-context</artifactId>
         <version>${springframework.version}</version>
     </dependency>
</dependencies>