maven坐标与依赖

坐标

--------在数学中, 任何一个坐标可以唯一确定一个“点”

Maven 中坐标是Jar包的唯一标识

坐标元素包括groupId、artifactId、version、packaging:

 

元素	描述	说明
groupId	定义当前模块隶属的实际Maven项目	中小企业常常直接对应公司/组织
artifactId	定义实际项目中的一个Maven模块	唯一标识一个模块
version	定义当前项目所处版本	SNAPSHOT 表示不稳定的版本。 LATEST 指最新发布的版本，可能是个发布版，也可能是一个snapshot版。 RELEASE 指最后一个发布版。
packaging	定义Maven项目打包方式	有jar(默认)、war、pom、maven-plugin等.
classifier	附属构件(如javadoc、sources)	须有附加插件的帮助

依赖

依赖即：A --》B，B--》C，C--》D这种项目间的依存关系。

在java的jvm内，依赖的最终表现是，项目A启动时，其依赖的jar包必须都对应放入其classpath路径内

依赖传递：

上述过程中，项目Mall归结起来，依赖的fastjson会有三个版本。

而我们的jvm最终肯定只能接受一个版本的jar，所以必须有所取舍

maven默认的取舍规则是：

1、路径最短原则：product和customer里的fastjson引用路径较短，路径为两步 ;pay项目里的fastjson引用路径较长，路径为三步。因此pay中的fastjson被淘汰

2、同路径长度下，谁先声明谁优先： product和customer中的fastjson路径相同，那么就看在pom中是先声明product还是先声明customer，谁先用谁的

依赖冲突及解决

在依赖传递里，我们看到，maven根据自己的规则为我们取舍出了一个版本的jar，但此jar版本选择可能会与我们的项目预期不符，

如：我们最终想的版本是fastjson:1.2.30版本-----但它在第一步即被淘汰掉了

当出现此类情况时，我们项目运行可能会出错（项目中使用到了1.2.30版本的特性）--------------- 此问题即是我们常遇到的jar包冲突问题

补救方式 ----- 使用exclusions将product和customer中的fastjson包排除掉，用法如下图：

当发生jar冲突程序报错时，可以使用mvn命令查出项目最终依赖的jar包树，看版本是否是我们预期的：

命令：     mvn dependency:tree

依赖范围scope

mvn在运行时，生命周期的不同阶段，会有不同的依赖范围，一般有以下依赖范围scope

- compile ：默认范围，用于编译 ------- 依赖的jar在打包时会包含进去      
- provided：类似于编译，但支持你期待jdk或者容器提供，类似于classpath   -------- 依赖的jar在打包时不会包含进去 
- runtime: 在执行时需要使用      -------依赖的jar在打包时会包含进去
- test:    用于test任务时使用       -------依赖的jar在打包时不会包含进去
- system: 需要外在提供相应的元素。通过systemPath来取得      ----- 一般禁止使用

 

每个scope实际上是配置了一个不同的classpath，jvm根据选择不同的classpath来达到依赖不同

环境激活---profiles的使用

在springmvc项目中，开发/测试/线上三个不同环境，配置文件往往也不同。

打包时需要对配置文件做出选择---maven提供了profiles机制供我们使用

profiles的场景

这个选择，实际发生在default生命周期的resource阶段---maven-resources-plugin执行过程里

定义profiles

为了指导插件将对应的resource文件打入classpath里，先定出profiles

此定义即指，当mvn命令执行时，我们需要通过 -P dev或者-P test方式传入我们的意图：

dev/test选择，会导致properties里的变量值含义不同，我们主要关注package.environment变量

资源插件的配置指定

配置maven-resources-plugin插件执行时，要复制的目录资源

mvn约定的资源中需要过滤掉环境目录

需要将mvn约定的资源目录里，过滤掉环境目录

小属性更轻便的用法

对于简单的属性，我们可以选择更轻便的用法

直接在环境中定义属性值

项目属性文件配置

 

约定的资源启用替换过滤