码迷,mamicode.com
首页 > 其他好文 > 详细

Maven专题1——坐标与依赖

时间:2019-08-06 21:31:42      阅读:77      评论:0      收藏:0      [点我收藏+]

标签:war   group   The   树形结构   路径   删除   移植   compile   元素   

坐标

坐标用来唯一定位一个Maven构件:

  • GAV(必需):groupId, artifactId, version
  • packaging(可选): 可取值如:jar(缺省), war, pom, maven-plugin等,其中父项目的packaging通常是pom,只用来声明项目元数据,用到的依赖、插件,以及项目中的子模块等。
  • classifier: 不能直接定义,通常用来辅助定义附属构件,如:javadoc、sources构件等。

依赖

在POM的<dependency>元素中,有以下元素可以用来配置依赖:

  • GAV:groupId、artifactId、version。

  • type:对应于被依赖模块的packaging元素的值。

  • scope:

compile:默认依赖范围,对编译、测试、运行三种classpath都有效,用于编译、测试、运行阶段都需要用到的依赖;
test:只对测试classpath有效,编译主代码、运行项目时无法使用的依赖。
provided:对编译、测试有效,在运行时无效。
runtime:运行时依赖,对测试、运行classpath有效,在编译主代码时无效;
import:不会对编译、测试、运行的classpath产生实际影响,
system:需通过systemPath显式指定依赖的路径,不通过Maven仓库解析,会造成构建的不可移植,不推荐使用。

  • optional:标记依赖是否可选;

  • exclusions:排除某些传递依赖。

管理typepom类型的依赖

通常一个项目的pom类型的构件用来声明使用到的依赖,为了沿用和管理其声明的所有依赖,通常可以在dependencyManagement元素中如下引用:

<dependencyManagement>
    <dependencies>
        <dependency>
            <artifactId>org.springframework.boot</artifactId>
            <groupId>spring-boot-dependencies</groupId>
            <version>${spring.boot.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

以此来保持我们项目使用的依赖和Spring Boot声明的一致。

依赖范围与classpath关系

依赖范围 对编译classpath有效 对测试classpath有效 对运行时classpath有效 示例
compile Y Y Y spring-core
provided Y Y - servlet-api
runtime - Y Y JDBC驱动
test - Y - JUnit
system Y Y - 本地Maven仓库以外的类库文件

依赖范围与依赖传递的关系

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

表格说明:

  1. 最左侧列是第一直接依赖,如A依赖于B,B依赖于C时,A对于B即是第1直接依赖;
  2. 最上侧行是第2直接依赖,如A依赖于B,B依赖于C时,B对于C即是第2直接依赖;
  3. 表中其他单元格表示传递依赖的依赖范围,即A传递依赖C的范围。

结论:

  1. 第2直接依赖的范围是compile时,传递依赖的范围与第1直接依赖一致;
  2. 第2直接依赖是test时,依赖不会传递;
  3. 第2直接依赖是provided时,只传递依赖第1直接依赖也是provided范围的依赖。

依赖调解

  1. 路径最近者优先,例如:A->B->c->x(1.0),a->d->x(2.0),由于a通过第二条路径依赖x的距离更短,因此实际解析使用的是2.0的x。
  2. 最先声明者优先,例如:a->b->y(1.0),a->c->y(2.0),在依赖路径等长时,声明依赖b在声明c之前,则实际解析使用的是y(1.0)。

可选依赖

optional元素是true的依赖是可选依赖。

可选依赖通常用来阻断依赖传递,例如a->b,b->x(可选)、b->y(可选)。

这种情况通常出现在b有多种实现,一种可以使用x,另一种可以使用y的场景。

此时考虑非可选的场景,如果上述3个依赖范围都是compile,那么x和y也应该是a的compile依赖。

然而在可选依赖的场景下,依赖传递被打破,x和y只会对声明可选依赖于他们的b有影响,a并不会传递依赖x和y。

当声明a依赖于b时,就要指明a选择使用b依赖的x还是y,即需要在a中显式的声明依赖x或y。

对于存在可选依赖的场景,应考虑针对每一种可选依赖建立一个独立的模块对外提供功能,从而不使用可选依赖这个概念。

优化依赖

使用列表的形式查看依赖:

mvn dependency:list

使用树形结构查看依赖树:

mvn dependency:tree

分析依赖状况:

mvn dependency:analyze

analyze会列出两类重点关注的依赖:

  1. 使用但未声明的依赖:指项目中使用到,但是是通过传递依赖传递进来的。
  2. 声明但未使用的依赖:项目中声明了但未使用的依赖,该命令只列出编译主代码、测试代码需要的依赖,并不会发现执行测试和运行时需要的依赖,所以不应该简单地删除声明了但未使用的依赖。

Maven专题1——坐标与依赖

标签:war   group   The   树形结构   路径   删除   移植   compile   元素   

原文地址:https://www.cnblogs.com/zyon/p/11294226.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有 京ICP备13008772号-2
迷上了代码!