【项目管理工具】Maven学习笔记(二)Maven依赖管理

文章目录


#1 坐标和依赖配置

  • Maven坐标的元素包括groupId、artifactId、version、packaging、classifier
    • groupId:定义当前Maven项目隶属的实际项目
    • artifactId:该元素定义实际项目中的一个Maven项目(模块),推荐的做法是使用实际项目名称作为artifactId的前缀
    • version:该元素定义Maven项目当前所处的版本
    • packaging:该元素定义Maven项目的打包方式
    • classifier:该元素用来帮助定义构建输出的一些附属构件,注意,不能直接定义项目的classifier,因为附属构件不是项目直接默认生成的,而是由附加的插件帮助生成
    • scope:用来定义依赖范围
    • type:依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认值为jar
    • optional:标记依赖是否可选
    • exclusions:用来排除传递性依赖
  • 大部分依赖声明只包含基本坐标,然而在一些特殊情况下,其他元素至关重要。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.companyname.myapp</groupId>
    <artifactId>project</artifactId>
    <version>1.0-SNAPSHOT</version>

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

#2 依赖范围

  • 依赖范围就是用来控制依赖与三种classpath(编译classpath、测试classpath、运行classpath)的关系,Maven有以下几种依赖范围:
    • compile:编译依赖范围。如果没有指定,就会默认使用该依赖范围。使用此依赖范围的Maven依赖,对于编译、测试、运行三种classpath都有效。
    • test:测试依赖范围。使用此依赖范围的Maven依赖,只对于测试classpath有效,在编译主代码或者运行项目的使用时将无法使用此类依赖。
    • provided:已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试class-path有效,但在运行时无效。
    • runtime:运行时依赖范围。使用此依赖范围的Maven依赖,对于测试和运行class-path有效,但在编译主代码时无效。
      #3 传递性依赖
  • 依赖的传递性:就是依赖的依赖,Maven会解析各个直接依赖的POM,将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目中
  • 依赖传递规则:
    • 当第二直接依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致;
    • 当第二直接依赖的范围是test的时候,依赖不会得以传递;
    • 当第二直接依赖的范围是provided的时候,只传递第一直接依赖范围也为provided的依赖,且传递性依赖的范围同样为provided;
    • 当第二直接依赖的范围是runtime的时候,传递性依赖的范围与第一直接依赖的范围一致,但compile例外,此时传递性依赖的范围为runtime。
表3-1 依赖传递规则
|第一直接依赖|compile|test|provided|runtime| |-|-|-|-|-| |compile|compile|停止传递|停止传递|runtime| |test|test|停止传递|停止传递|test| |provided|provided|停止传递|provided|provided| |runtime|runtime|停止传递|停止传递|runtime| #4 依赖调节 - 当出现两个间接依赖相同的时候,通过依赖调解来决定引用哪个依赖(Maven中不可重复引用同一依赖) - Maven依赖调解(Dependency Mediation)的原则: - 第一原则:路径最近者优先。 - 第二原则:第一声明者优先。在依赖路径长度相等的前提下,在POM中依赖声明的顺序决定了谁会被解析使用,顺序最靠前的那个依赖优胜。 #5 可选依赖 - 设有这样一个依赖关系,项目A依赖于项目B,项目B依赖于项目X和Y,B对于X和Y的依赖都是可选依赖:A->B、B->X(可选)、B->Y(可选),由于这里X、Y是可选依赖,依赖将不会得以传递。可选依赖一般出现在系统提供互斥的功能,只能二选一的情形。 - 使用<optional>元素表示依赖为可选依赖,它们只会对当前项目产生影响,当其他项目依赖于本项目的时候,可选依赖不会被传递。如需引用,只能直接引用。 ``` <?xml version="1.0" encoding="UTF-8"?> 4.0.0
<groupId>com.companyname.myapp</groupId>
<artifactId>project</artifactId>
<version>1.0-SNAPSHOT</version>

<dependencies>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.10</version>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <version>8.4-701.jdbc3</version>
        <optional>true</optional>
    </dependency>
</dependencies>
``` #6 排除依赖 - 使用exclusions元素声明排除依赖,exclusions可以包含一个或者多个exclusion子元素,因此可以排除一个或者多个传递性依赖。需要注意的是,声明exclusion的时候只需要groupId和artifactId,而不需要version元素,这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说,Maven解析后的依赖中,不可能出现groupId和artifactId相同,但是version不同的两个依赖 - 排除依赖一般用于解决依赖传递带来的不稳定性 ``` <?xml version="1.0" encoding="UTF-8"?> 4.0.0
<groupId>com.companyname.myapp</groupId>
<artifactId>project</artifactId>
<version>1.0-SNAPSHOT</version>

<dependencies>
    <dependency>
        <groupId>com.juvenxu.mvnbook</groupId>
        <artifactId>project-b</artifactId>
        <version>1.0.0</version>
        <exclusions>
            <exclusion>
                <groupId>com.companyname.myapp</groupId>
                <artifactId>project-c</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>com.companyname.myapp</groupId>
        <artifactId>project-c</artifactId>
        <version>1.1.0</version>
    </dependency>
</dependencies>
#7 归类依赖
- 如果一些依赖是来自同一项目的不同模块。因此,所有这些依赖的版本都是相同的,而且可以预见,如果将来需要升级某个依赖,这些依赖的版本会一起升级。通过使用properties元素定义Maven属性,有了这个属性定义之后,Maven运行的时候会将POM中的所有的相同信息替换成实际值。也就是说,可以使用美元符号和大括弧环绕的方式引用Maven属性。
<?xml version="1.0" encoding="UTF-8"?>


4.0.0

<groupId>com.companyname.myapp</groupId>
<artifactId>project</artifactId>
<version>1.0-SNAPSHOT</version>

<properties>
    <springframework.version>2.5.6</springframework.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${springframework.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context-support</artifactId>
        <version>${springframework.version}</version>
    </dependency>
</dependencies>
#8 优化依赖
- Maven会自动解析所有项目的直接依赖和传递性依赖,并且根据规则正确判断每个依赖的范围,对于一些依赖冲突,也能进行调节,以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后,最后得到的那些依赖被称为已解析依赖(Resolved Dependency)。可以运行如下的命令查看当前项目的已解析依赖:`dependency:list`
- 在此基础上,还能进一步了解已解析依赖的信息。将直接在当前项目POM声明的依赖定义为顶层依赖,而这些顶层依赖的依赖则定义为第二层依赖,以此类推,有第三、第四层依赖。当这些依赖经Maven解析后,就会构成一个依赖树,通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以运行如下命令查看当前项目的依赖树:`dependency:tree`
- 使用`dependency:list`和`dependency:tree`可以帮助我们详细了解项目中所有依赖的具体信息,在此基础上,还有`dependency:analyze`工具可以帮助分析当前项目的依赖,分析的结果中重要的是两个部分。
	- 首先是Used undeclared dependencies,意指项目中使用到的,但是没有显式声明的依赖,这种依赖意味着潜在的风险,当前项目直接在使用它们,这种依赖是通过直接依赖传递进来的,当升级直接依赖的时候,相关传递性依赖的版本也可能发生变化,这种变化不易察觉,但是有可能导致当前项目出错。例如由于接口的改变,当前项目中的相关代码无法编译。这种隐藏的、潜在的威胁一旦出现,就往往需要耗费大量的时间来查明真相。因此,显式声明任何项目中直接用到的依赖。
	- 其次是Unused declared dependencies,意指项目中未使用的,但显式声明的依赖。需要注意的是,对于这样一类依赖,我们不应该简单地直接删除其声明,而是应该仔细分析。由于`dependency:analyze`只会分析编译主代码和测试代码需要用到的依赖,一些执行测试和运行时需要的依赖它就发现不了。当然,有时候确实能通过该信息找到一些没用的依赖,但一定要小心测试。
















  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值