4、Maven坐标&依赖

groupId、artifactId、version共同组成一个坐标来唯一确定该项目在仓库中的位置

当正确配置maven的依赖后，maven会从中央仓库下载对应的依赖

相关信息在已在 ## 2.2 提到

maven打出来的包名一般按照artifactId-version[-classifier].packaging的规约生成

1.1、依赖(dependency)的具体元素

• groupId
• artifactId
• version
• type：可以不声明，默认为jar
• scope：可以不声明，默认为compile
• optional：表示依赖是否可选
• exclusions：排除传递性依赖

1.2、依赖范围(scope)

• compile：对于编译、测试、运行三种生命周期的test/main下的源代码都有效，默认为这个

• test：只对于测试的生命周期的test目录下的代码有效，如JUnit

• provided：对于编译、测试两种生命周期的test/main下的源代码都有效，如servlet-api，容器可以提供这个，所以运行时不用maven提供依赖

• runtime：测试和运行时的test/main下的代码有效，如JDBC驱动

• system：对于编译、测试两种生命周期的test/main下的源代码都有效，但是要与本机的系统路径绑定，一致性不强，也不是由maven仓库解析

  
    ....
    system
    ${java.home}/lib/rt.jar
  
  

• import：导入依赖范围，不对依赖的生命周期不会有实际影响

1.3、传递性依赖

A依赖B，B依赖C，那么C就是A的传递性依赖

• 当第二直接依赖的范围是compile时，传递性依赖的范围与第一直接依赖一致
• 当第二直接依赖的范围是test时，传递性依赖不会得到传递
• 当第二直接依赖的范围是provide时，只传递第一直接传递范围为provide的依赖，且范围也是provide
• 当第二直接依赖的范围是runtime时，传递性依赖范围与第一直接依赖范围一致，但compile不一样，传递依赖为runtime

1.4、依赖调解

有如下依赖路径：

A -> B -> C -> X (1.0)

A -> D -> X (2.0)

两条路径都引用了X，此时Maven会选用最短路径原则，那么第二条路径会被运用

有如下依赖路径：

A -> C -> X (1.0)

A -> D -> X (2.0)

两条路径都引用了X，且路径长度一致，此时Maven会选用最先声明原则，在pom文件先声明的依赖会被启用，那么第一条路径会被运用

1..5、排除传递性依赖

排除依赖只需要groupId和artifactId

    ....
    
        
            ···
            ···
        
    

1.6、依赖归类

同一项目的不同包可能优势用的版本是一样的，我们可以用Maven的属性来进行统一管理

    1.0.0

然后在dependency的version中使用${a.version}引用即可

1.7、优化依赖

Maven会解析项目的直接依赖和传递依赖，并且正确判断依赖范围，可以调节依赖冲突来保证只有一个版本正确引用，完成后的依赖叫已解析依赖

• 查看依赖列表

  cmd:mvn dependency:list
  

• 查看依赖树状图

  cmd:mvn dependency:tree
  

• 分析项目依赖使用情况

  cmd:mvn dependency:analyze
  

  可以查看依赖是否被使用等等

  此处怀疑只能看到scope为compile而没被用到的依赖，scope为provided但实际在项目中要用到的依赖同样会显示unused dependency