maven日记（二）：坐标和依赖

>> maven坐标由5个元素组成：

* groupId：定义当前maven项目隶属的实际项目

maven项目和实际项目不一定是一对一关系，比如SpringFramework这一实际项目，其对应的maven项目会有很多，比如spring-core、spring-context等。这是由于maven中模块的概念，因此一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司，因为一个组织下面会有很多项目。最后，groupId表示方式与Java包名表示方式类似，通常与域名反向一一对应。比如org.sonatype.nexus，org.sonatype是公司域名，而nexus表示Nexus这一实际项目，该groupId与nexus.sonatype.org域名对应。

* artifactId：定义实际项目中的一个maven项目（模块），推荐做法是使用实际项目名称作为artifact的前缀，比如nexus-indexer

* version：定义maven项目当前所处的版本

* packaging：定义maven项目打包方式，默认为jar

* classifier：定义构建输出的一些附属构件，附属构件与主构件对应，如nexus-indexer-2.0.0.jar，该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar等附属构件，这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就拥有了自己的唯一坐标。注意classifier是不能直接定义的，它是由附加插件帮助生成的。

注：构件生成的文件名规则为：artifactId-version[-classifier].packing，此外，maven仓库的布局也是基于maven坐标。

>> 依赖的配置：

<dependencies>
    <dependency>
        <groupId>com.icegreen</groupId>
        <artifactId>greenmail</artifactId>
        <version>1.3.1b</version>
        <type>...</type>
        <scope>test</scope>
        <optional>...</optional>
        <exclusions>
            <exclusion>
            ...
            </exclusion>
            <exclusion>
            ...
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
    ...
    </dependency>
</dependencies>

每个依赖可以包含的元素有：

* groupId、artifactId和version：依赖的基本坐标

* type：依赖的类型，对应于项目坐标定义的packaging，大部分情况下都为默认的jar

* scope：依赖的范围

* optional：标记依赖是否可选

* exclusions：排除传递性依赖

>> 依赖范围scope

依赖范围就是用来控制依赖与这三种classpath（编译classpath、测试classpath、运行classpath）的关系，maven有以下几种依赖范围：

* compile：编译范围，如果没有指定，默认就是这个范围，使用此范围的maven依赖，对于编译、测试、运行三种classpath都有效。

* test：测试依赖范围，只对测试classpath有效，在编译主代码或者运行项目的时候无法使用此依赖，典型就是junit

* provided：已提供依赖范围。对于编译和测试有效，但在运行时无效。典型例子就是servlet-api，编译和测试项目时候需要用到该依赖，但在运行项目的时候，由于容易已经提供，就不需要重复的引入了。

* runtime：运行时依赖，对于测试和运行有效。但是编译无效，典型就是JDBC-Driver实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述具体的JDBC驱动。

* system：系统范围依赖。该依赖于三种classpath的关系，和provided完全一致。但是，使用system范围的依赖时候必须通过systemPath元素显示指定依赖文件的路径。由于此类依赖不是通过maven仓库解析的，而是往往与本机系统绑定，可能造成构建的不可移植，因此谨慎使用，systemPath可以引用环境变量，如：

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

* import：导入依赖范围。该依赖不会对三种classpath产生实际影响

图示说明依赖范围与classpath关系：

依赖范围	compile有效	test有效	runtime有效
compile		Y			Y			Y
test		--			Y			--
provided	Y			Y			--
runtime		--			Y			Y
system		Y			Y			--

>> 传递性依赖

依赖范围不仅可以控制依赖与三种classpath的关系，还对传递依赖产生影响。比如：account-email依赖spring-core，而spring-core依赖commons-logging。account-email对于spring-core的依赖范围是compile，spring-core对于commons-logging依赖范围是compile，那么account-email对于commons-logging这一传递依赖范围就是comile。假设A依赖B，B依赖C，我们说A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖范围决定了传递依赖的范围。

图示依赖范围影响传递依赖：table首列为第一直接依赖，table首行是第二直接依赖，table数据为传递依赖影响范围

1 2 3 4 5

compile     test    provided    runtime compile     compile     --      --          runtime test        test        --      --          test provided    provided    --      provided    provided runtime     runtime     --      --          runtime

>> 依赖调解：

如果A -> B -> C -> X1.0，然后还有一个 A -> D -> X2.0，一个项目依赖X的两个版本，那么应该选哪个呢，maven依赖调解原则：

第一原则：路径最近者优先，比如上面，肯定是X2.0路劲优先

第二原则：如果路径长度一样，那么第一声明者优先，也就是在pom的dependence里面优先声明的优先使用。哦也~~

>> 可选依赖

如果A -> B，而B -> X并且 B-> Y，但是如果X和Y是optional的时候，A不依赖X和Y，也就是X和Y不会被传递。

<dependencies>
    <dependency>
        <groupId>...</groupId>
        <artifactId>...</artifactId>
        <version>1.0.0</version>
        <optional>true</optional>
    </dependency>
</dependencies>

当其他项目需要依赖这个jar包的时候，需要自己去显示的声明。但是在理想情况下，是不应该出现这个传递依赖的。

>> 排除依赖

可以使用exclusion排除传递依赖，不解释

>> 归类依赖

在pom中定义版本变量version，统一使用版本变量名，方便升级，不解释

>> 优化依赖

项目中引入各种依赖的时候，可能会有很多依赖相同的jar包但是版本不一致的，但是maven非常智能的通过它的依赖调解最后确保只会引用唯一一个版本。

可以运行命令 ：

mvn dependency:list：去查看当前项目已解析的依赖列表

mvn dependency:tree：以树状结构查看依赖树

mvn dependency:analyze：分析项目的依赖问题

 

本人博客已搬家，新地址为：http://yidao620c.github.io/