坐标

坐标（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之后定义了第二则，即第一声明者优先。