Maven详解(五)------ 坐标的概念以及依赖管理

  我们知道maven能帮我们管理jar包,那么它是怎么管理的呢?这篇博客我们来详细介绍。

1、什么是坐标?

①、数学中的坐标

    在平面上,使用 X 、Y 两个向量可以唯一的定位平面中的任何一个点

    在空间中,使用 X、Y、Z 三个向量可以唯一的定位空间中的任意一个点

②、Maven 中的坐标

    俗称 gav:使用下面三个向量子仓库中唯一定位一个 Maven 工程

    在项目中的 pom.xml 文件中,我们可以看到下面gav的定义:

    1、groupid:公司或组织域名倒序 

      <groupid>com.ys.maven</groupid>

    2、artifactid:模块名,也是实际项目的名称

      <artifactid>Maven_05</artifactid>

    3、version:当前项目的版本

      <version>0.0.1-SNAPSHOT</version>

③、Maven 坐标和仓库,jar 包的关系

什么是仓库,后面我们会详细讲解,现在你只需要知道是Maven 用来存放 jar 包的地方。

    那么依照上面定义的 gav,我们执行 mvn -install 命令,会出现什么情况呢?

    首先进入到我们第二篇博客 Maven 的安装配置 ,通过 settings.xml 文件配置的仓库目录。

      将我们上面配置的 gav 向量组合起来就是目录:

      com/ys/maven/Maven_05/0.0.1-SNAPSHOT/Maven_05-0.0.1-SNAPSHOT.jar

    其次,我们观察打出来的 jar 包:

      Maven_05-0.0.1-SNAPSHOT.jar

    也就是 artifactid-version.jar

2、什么是依赖? 

   什么是 依赖?相信有过一定开发经验的人知道,每当我们需要使用某个框架时,比如 SpringMVC,那么我们需要导入相应的 jar 包,但是手动导入包的时候,往往会漏掉几个 jar 包,那么在使用该框架的时候系统就会报错。那么我们就说导入的包与未导入的包存在依赖关系。而使用 Maven,我们只需要在 pom.xml 文件中进行相应的配置,它就会帮助我们自动管理 jar 包之间的依赖关系。那么它是怎么管理的呢,接下来我们会详细讲解。

3、依赖的详细配置

  我们以 Junit 为例,在 pom.xml 文件中进行详细而完整的配置。 

<project>      
    <dependencies> 
        <dependency>
            <groupId>junit</groupId>      
            <artifactId>junit</artifactId>      
            <version>3.8.1</version>
            <type>...</type>
            <scope>...</scope>
            <optional>...</optional>
            <exclusions>      
                <exclusion>      
                  <groupId>...</groupId>      
                  <artifactId>...</artifactId>      
                </exclusion> 
          </exclusions>      
        </dependency>         
      </dependencies>      
</project>

  ①、dependencies:一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签。

  ②、dependency:包含在dependencies标签中,可以有无数个,每一个表示一个依赖

  ③、groupId,artifactId和version:依赖的基本坐标,对于任何一个依赖来说,基本坐标是最重要的,Maven根据坐标才能找到需要的依赖。

  ④、type:依赖的类型,对应于项目坐标定义的packaging。大部分情况下,该元素不必声明,其默认值是jar。

  ⑤、scope:依赖的范围,默认值是 compile。后面会进行详解。

  ⑥、optional:标记依赖是否可选。

  ⑦、exclusions:用来排除传递性依赖,后面会进行详细介绍。

4、依赖的范围 scope 

  一般情况下,我们对前面三个依赖用的比较多。下面的主程序表示maven 目录结构 src/main/java.测试程序目录结构为:src/test/java

1、compile 范围依赖

    对主程序是否有效:有效

    对测试程序是否有效:有效

    是否参与打包:参与

    是否参与部署:参与

    典型例子:log4j

2、test 范围依赖

    对主程序是否有效:无效

    对测试程序是否有效:有效

    是否参与打包:不参与

    是否参与部署:不参与

    典型例子:Junit

3、provided 范围依赖

    对主程序是否有效:有效

    对测试程序是否有效:有效

    是否参与打包:不参与

    是否参与部署:不参与

    典型例子:servlet-api.jar,一般在发布到 服务器中,比如 tomcat,服务器会自带 servlet-api.jar 包,所以provided 范围依赖只在编译测试有效。

4、runtime 范围依赖:在测试、运行的时候依赖,在编译的时候不依赖。例如:JDBC驱动,项目代码只需要jdk提供的jdbc接口,只有在执行测试和运行项目的时候才需要实现jdbc的功能。

   接下来我们举几个例子在工程中实际去理解:

test 依赖和 compile 依赖的区别:

    ①、首先我们在 pom.xml 文件中配置,Junit 的 test 依赖

    ②、我们在主程序中去导入 Junit 的包,然后进行 mvn -compile 编译,很明显,test 范围的在主程序中无效,故编译会报错。

      我们在 src/main/java 包下新建 MavenTest.java,并导入 Junit 包

      然后执行 mvn -compile 操作,如下图报错信息:

    ③、我们将 Junit 的依赖范围改为 compile,然后执行 mvn -compile

      发现 mvn -compile 没有报错了。

4、依赖的传递

  比如我们创建三个Maven 工程,maven-first,maven-second以及maven-third,而third依赖于second,second又依赖于first,那么我们说 second 是 third 的第一直接依赖,first是second的第二直接依赖。而first是third的间接依赖。

   依赖之间的传递如下图:第一列表示第一直接依赖,第一行表示第二直接依赖

总结:

1、当第二依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致。
2、当第二直接依赖的范围是test的时候,依赖不会得以传递。
3、当第二依赖的范围是provided的时候,只传递第一直接依赖范围也为provided的依赖,且传递性依赖的范围同样为 provided;
4、当第二直接依赖的范围是runtime的时候,传递性依赖的范围与第一直接依赖的范围一致,但compile例外,此时传递的依赖范围为runtime;

  我们这里举个例子来看:

  ①、第二依赖范围是 test

    Maven_first 的pom.xml 文件如下:

    然后Maven_second依赖Maven_fisrt,Maven_third依赖Maven-second,其pom.xml 文件如下:

    Maven_second的 pom.xml

    Maven_third的 pom.xml

    我们发现在 Maven_third和 Maven_second 都没有 Maven_first 引入的 Junit 包,正好符合上面总结的第二点:当第二直接依赖的范围是test的时候,依赖不会得以传递。

     ②、第二依赖范围是 compile

     如果我们将 Maven_first 的Junit 改为 compile,那么将会符合上面总结的第一点:当第二依赖的范围是compile的时候,传递性依赖的范围与第一直接依赖的范围一致。

5、依赖的排除

  如果我们在当前工程中引入了一个依赖是 A,而 A 又依赖了 B,那么 Maven 会自动将 A 依赖的 B 引入当前工程,但是个别情况下 B 有可能是一个不稳定版,或对当前工程有不良影响。这时我们可以在引入 A 的时候将 B 排除。

  比如:我们在Maven_first 中添加 spring-core,maven 会自动将 commons-logging添加进来,那么由于 Maven_second 是依赖 Maven_first  的,那么 Maven_second  中将存在 spring-core(自带了commons-logging),这时候我们不想要 commons-logging,那该怎么办呢?我们上面第二大点提到了:

exclusions:用来排除传递性依赖

  Maven_first 的 pom.xml 文件

  由于 Maven_second 依赖 Maven_second,故Maven_second 存在 spring-core 包

   如何排除呢?我们在 Maven_second 的 pom.xml 文件中添加如下代码:

  再次查看工程:Maven_second 的 commons-logging 已经移除了

6、依赖的冲突

  在maven中存在两种冲突方式:一种是跨pom文件的冲突,一致是同一个pom文件中的冲突。

①、跨 pom 文件,路径最短者优先。比如我们在 Maven_first 中的 Junit 是4.9版本的,Maven_second 中的 Junit 是4.8版本的,那么Maven_third 中的 Junit 将会是那个版本呢?

  由上图我们可以看出,由于 Maven_second 是 Maven_third 的直接依赖,明显相比于 Maven_first 路径要短,所以 Maven_third 的 Junit 版本与 Maven_second 保持一致。

②、同一个pom.xml 文件,先申明者优先。

看 Maven_second

7、可选依赖

  Optional标签标示该依赖是否可选,默认是false。可以理解为,如果为true,则表示该依赖不会传递下去,如果为false,则会传递下去。

  我们是在 Maven_second 的 pom 文件中设定 Junit 不可传递,那么Maven_third 工程中将不会有来自 Maven_second 的 Junit 的传递。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏雨过天晴

转 Linux防火墙之具有命令行的FirewallD的基本操作

1593
来自专栏运维小白

Linux基础(day53)

12.21 php-fpm的pool php-fpm的pool目录概要 vim /usr/local/php/etc/php-fpm.conf//在[globa...

18210
来自专栏FreeBuf

史上最全的njRAT通信协议分析

*本文原创作者:菠菜,本文属FreeBuf原创奖励计划,未经许可禁止转载 Njrat,又称Bladabindi,该木马家族使用.NET框架编写,是一个典型的RA...

2056
来自专栏存储

SMB共享之SCF文件攻击解析

SMB是各类组织中广泛使用的一种文件共享协议,而且在很多内部渗透测试过程中,研究人员可以利用这种协议来发现共享文件中包含的敏感信息(例如明文密码和数据库连接信息...

19910
来自专栏Rainbond开源「容器云平台」

敲黑板 | 云帮储存那点事儿

1383
来自专栏FreeBuf

Makednslog:让我们来看一看这款能够伪造DNS日志的工具

写在前面的话 2016年8月1日,我曾发表过一篇文章【点击文末的阅读原文查看】并介绍了如何使用哈希算法来提升大型DNS日志文件的搜索效率。但是这篇文章中还存在一...

2016
来自专栏编程坑太多

『中级篇』手动建立一个base Image(14)

PS:hello.c 因为是c语言写的,我们把它打成一个Image,Image里面其实就是一个可以执行的文件,它其实依赖宿主机kernel,它虽然比较小,但是也...

1416
来自专栏FreeBuf

初识Linux渗透:从枚举到内核利用

许多人都认为Linux是最安全的操作系统,因此在对Linux的安全问题上也放松了警惕。那么事实真的如此吗?其实安全从来都只是相对的,Linux也不例外。虽然它加...

1186
来自专栏三木的博客

Linux基础知识总结

###一:什么是Linux? Linux被称为类Unix操作系统,遵循POSIX标准。Linux与Unix的最大不同在于源代码的开放性和自由性。 Linux的发...

1839
来自专栏FreeBuf

文件监控程序V2.0改进版(网站防挂马好手)

前言 技多不压身,多掌握几种不同的编程语言,不但有助于开拓我们的视野,还可以让我们在工作时,自己写一些小程序来帮我们减少工作量。 前段时间给一个客户维护服务器,...

1695

扫码关注云+社区