坐标
坐标（Coordinate）是用来标识或者定位资源的，上节中我们为自已的HelloWorld工程定义了坐标，在引用Junit时也是通过坐标来引用的。就好比邮编地址一样，定义了省市县乡村街道，快递小哥才能上门送件或取件。
- groupId
- artifactId
- version
- packaging
- classifier
groupId定义当前的Maven项目所属的项目名称，比如apache组织的tomcat项目定义为org.apache.tomcat，前边为公司组织的域名，后边为项目名称。而artifactId则表示当前项目的模块名称，一般推荐以项目名称作为前缀，比如tomcat-catalina，tomcat-jdbc等，原因是maven打包时会使用artifactId命名，比如tomcat-catalina-9.0.8.jar，这样通过jar包名称可以直观的知道所属项目了。
我们再看下spring的坐标定义：
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.0.6.RELEASE</version>
spring直接使用域名org.springframework，但是spring的项目名称本身就是springframework，所以就不是com.xx.xx的格式了。而spring的每个模块类似的有spring-context、spring-test。但是后来的springcloud项目命名发生变化了，他是org.springframework.cloud，每个模块有spring-cloud-context、spring-cloud-commons等等。这样就发生了groupId的不一致的问题，当然这个不是什么致命问题，但建议我们一开始在架构maven工程时就提前设计好命名。格式如下：
groupId:com.公司名称.项目名称
artifactId:项目名称-模块名称
在maven仓库http://mvnrepository.com可以查看每个项目或模块的坐标定义
version定义版本号
packaging定义打包格式，jar或者war，也可以是zip等格式
classifier定义附属构件，用来生成包含javadoc或者源码的jar包。因为这个不是项目默认直接生成的，需要附加插件帮助，所以不可以直接使用。
依赖（scope）
在进行配置依赖包时可以使用以下模板
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
<type></type>
<optional></optional>
<exclusions>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
</dependencies>
type:依赖的类型，对应的是packaging类型，默认的情况下jar类型
scope:依赖的范围，
optional:依赖是否可选
exclusion:用来排除传递性依赖
scope-依赖范围
我们知道java工程在编译、测试、运行时都会依赖到我们引用的第三方jar包。但是有些jar包可能只会在测试的时候使用，也有可能只在运行的时候使用，也有可能三个过程都使用。这样就需要我们在maven管理的jar包的时候指定其依赖的作用范围。依赖范围的配置有以下几种：
- compile
- test
- provided
- runtime
- system
- import
compile:编译依赖范围，如果不指定则默认为此依赖范围。在编译、测试、运行都会引用该依赖。
test:测试依赖范围，表示该依赖只在测试时会使用。比如junit，只有测试的时候会使用，注意：测试也存在编译。compile是指主代码的编译
provided:已提供依赖范围，只在编译和测试期有效，最常见的就是servlet开发，我们开发web时一般会引用tomcat的jar包，尤其是servlet包。但是在部署的时候就不会把这些依赖包再次打包部署，否则会造成包冲突
runtime:运行时依赖范围，这个一般不是很多见。表示在测试、运行时有效，编译无效
system:系统依赖范围，和provided一致，但是需要使用systemPath来指定包的依赖包的路径
import:导入依赖范围，这种依赖不会对编译、测试、运行造成影响，在使用dependencyManagement会用到，后续会介绍。
| 依赖范围 | 编译classpath有效 | 测试classpath有效 | 运行classpath有效 | 例子 |
|---|---|---|---|---|
| compile | Y | Y | Y | spring-core |
| test | - | Y | - | junit |
| provided | Y | Y | - | servlet-api |
| runtime | - | Y | Y | JDBC驱动 |
| system | Y | Y | - | 本地的，Maven仓库以外的类库 |
scope-依赖性传递
| - | compile | test | provided | runtime |
|---|---|---|---|---|
| compile | compile | - | - | runtime |
| test | test | - | - | test |
| provided | provided | - | provided | provided |
| runtime | runtime | - | - | runtime |
在我们在pom文件中引入Spring-Freamework:spring-core依赖时需要引用spring-core的jar包，但是spring-core的jar包又需要用到commons-logging:commons-logging。这样就会引起依赖传递。使用的时候我们只需要关心spring-core就可以了，不用考虑spring-core依赖了哪些包，正是Maven提供的这种机制，使我们可以很方便的管理依赖。
由于依赖的是范围的，所以传递的效果也是不一样的。假如spring-core中使用了junit包，并且scope是test，那我们的项目如果没有使用junit，那spring-core对junit的引入是没有必要的，因为我们的项目在运行时根本不需要junit。
为了更好的说明上述表示，我们定义一些概念。假如A依赖B，B依赖C，那么就可以说成是A对于B是第一直接依赖，B对于C是第二直接依赖，而A对于C则是传递性依赖。第一直接依赖的范围和第二直接依赖的范围，则决定了传递性依赖的范围。如上表格所示，最左一列表示第一直接依赖范围，最上一行表示第二直接依赖范围，交叉项则表示传递依赖的范围。
传递规律：
1、如果第二直接依赖范围为compile，则传递性依赖范围和第一直接依赖范围一样
2、如果第二直接依赖范围为test，则依赖范围不传递
3、如果第二直接依赖范围为provided，则只有当第一直接依赖范围为provided时进行传递
4、。。。
最后需要说明一下optional的使用，他是用来表示可选依赖。假如存在这样的依赖关系，A->B，B->X(可选)，B->Y(可选)，这种情况X和Y只对B起作用，对A没有任何影响。如果A需要使用到X或者Y，直接进行依赖就可以了。这种情况一般不推荐使用。
依赖冲突与二义
- 项目A存在这样的依赖关系，A->B->C->X(1.0)，A->D->X(2.0)，其中X是A的传递性依赖，当被依赖的对象存在不同的版本时，实际被maven解析的是路径最短的，即X(2.0)被解析。遵循maven的第一原则：路径最近原则
- 项目A存在这样的依赖关系，A->B->X(1.0)，A->D->X(2.0)，这种情况下X离A的两个路径一样长，第一原则无法解决这种问题，maven在2.0.9之后定义了第二则，即第一声明者优先。
