坐标

前面一章已经讲过了，在maven的世界里，所有的一切都是以坐标定位的，是时候对坐标做一个详细解释了

TIM图片20170721230132.gif

项目文件名
maven中项目文件名的生成完全依赖于坐标，生成的一般规则为:artifactId-version[-classifier].packaging

依赖

依赖是maven中一大核心，项目中用到的所有第三方资源都是通过依赖导入到项目中使用的，下面是依赖的基本架构：

<dependencies>
    <dependency>
        <groupId></groupId>
        <artifactId></artifactId>
        <version></version>
        <type></type>
        <scope></scope>
        <optional></optional>
        <exclusions>
            <exclusion>
                <groupId></groupId>
                <artifactId></artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

• groupId,artifactId,version为maven坐标系的基本坐标，对于每一个构建来说都是必须的
• type声明依赖的类型，与项目packaging对应，默认值为jar
• scope依赖范围，maven中对编译,测试,运行三个环境提供了6种依赖范围test,provide,import,compile,runtime,system，他们之间的具体关系将在下面讲到
• optional标记依赖是否为可选依赖，默认为false
• exclusions用来排除一些传递性依赖

依赖范围scope
在maven中有3中classpath：编译、测试、运行
围绕这三种classpath又分出了6种不同的依赖范围
compile(default),test,provide,runtime,system,import

图片1.png

    <groupId>javax.sql</groupId>
    <artifactId>jdbc-stdext</artifactId>
    <version>2.0</version>
    <scope>system</scope>
    <systemPath>${java.home}/lib/dt.jar</systemPath>
</dependency>

import导入依赖范围，该依赖范围不会对上面提到的三种classpath产生实际的影响，只针对dependencyManagement有效

传递性依赖
在引入一个依赖的时候，被引入的依赖同时又依赖了其他开源类库，这时该项目就发生了传递性依赖
maven传递性依赖为用户减少了配置依赖不必要的麻烦，我们在实际引入一个依赖时无需考虑该依赖是否还需要额外的引入其他开源类库，maven传递性依赖自动为我们处理了这类问题

传递性依赖和依赖范围
依赖范围(scope)不仅可以控制与三种classpath的关系，而且还会影响传递性依赖

图片2.png

图片4.png

从上面的图片中可以得出一些结论：

• 第二依赖如果是compile，那么最后得到的jar包依赖范围为第一依赖的值
• 第二依赖如果是test，则jar包将不被包含(依赖范围为空)
• 第二依赖如果是provide, 只有第一依赖为provide的jar包有效，且依赖范围为provide
• 第二依赖如果是runtime, 当第一依赖为compile时，最终依赖为runtime,其他范围不变

依赖调节
既然maven中存在传递依赖，那么又会存在一系列问题，比如

图片5.png

图片6.png

可选依赖
可选依赖的声明格式形如：

<dependency>
    ...
    <optional>true</optional>
    ...
</dependency>

可选依赖的一个使用场景是当对某一业务有不同实现，比如对数据库的操作，有jdbc,oracle等实现类库，但理想情况下是不应该使用可选依赖的，对于项目实现的多样性，可以抽离成不同的项目，让用户自己选择具体依赖实现，比如对jdbc实现分离出一个项目模块，对oracle实现又分离出另一个模块供用户选择性使用

依赖排除(exclusions)
在某些情况下，我们需要排除传递依赖的其他开源类库，而引入指定的类库，这时需要使用exclusions来对依赖进行排除

<dependency>
    <exclusions>
        <exclusion>
            <groupId></groupId>
            <artifactId></artifactId>
        </exclusion>
    </exclusions>
</dependency>

在对依赖进行排除时只需要指定groupId,artifactId即可，因为在一个pom文件中，优化的依赖不可能存在相同的groupId,artifactId不同的version的依赖存在

归类依赖(properties)
对于来自同一个项目的不同模块，他们的版本都是一致的，考虑到代码到简洁便于修改以及重复问题，可以将version放在一处统一管理,这里就需要用到properties元素

<properties>
    <spring.version>4.2.3</spring.version>
</properties>

在使用了属性变量后，在pom的依赖管理中使用到指定的变量就可以采用${property}的方式引用了，比如

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>${spring.version}</version>
</dependency>

依赖优化
我们可以借助maven提供的一些命令工具来了解当前依赖的具体情况

列表显示依赖情况list
mvn dependency:list
命令将会列出当前项目中使用的依赖包信息，包括版本、依赖范围等信息

图片7.png

树形结构显示依赖情况tree
mvn dependency:tree
将会以树形形式展现当前项目传递依赖的情况

图片8.png

分析依赖analyze
mvn dependency:analyze
使用上述命令可以了解当前项目在编译时有哪些使用到了但没有明确指定的依赖(used undeclared dependencies)以及明确指定但是没有被使用的依赖(unused declared dependencies)

图片9.png