Maven 坐标和依赖

Maven 坐标和依赖

 

Maven 的一大功能就是管理项目依赖,为了能自动化的解析任何一个 Java 构件,Maven 必

须将他们唯一标识,这就是依赖管理的底层基础“坐标”。

 

1. Maven 坐标是什么

    世界上任何一个构件都可以使用 Maven 坐标唯一标识,这些构件其实也就是平时使用的一些 jar、

    war 等文件。例如:

 

<groupId>com.lichee</groupId>
<artifactId>lichee-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>

 

    a) groupId

           定义当前 Maven 项目隶属的实际项目,groupId 的表示方式与 Java 包名的表示方式类似,

           通常与域名反向一一对应。

    b) artifactId

          该元素定义实际项目中的一个 Maven 项目(模块),推荐的做法是使用实际项目名称作为

          artifactId的前缀,好处在于方便寻找实际的构件(构件组)。

    c) version

           定义 Maven 项目所处的版本,Maven 定义了一套完整的版本规范。

    d) packaging

           定义 maven 项目的打包方式,默认值是 jar。

    e) classifier

           定义构建输出一些附属构件,附属构件与主构件对应,例如:javadoc.jar、

           sources.jar,这样附属构件也拥有了自己唯一的坐标。

 

上述 5 个元素,groupId、artifactId、version 是必须要定义的,packaging 是可选的,

classifier 是不能直接定义的。项目构件名的文件名是与坐标相对应的,

一般规则为artifactId-version[-classifier].packaging , [-classifier] 表 示 可 选 。

packing 并非一定与构件扩展名对应,比如 packing 为 maven-plugin 的构件扩展名为 jar。

 

2. 依赖的配置

    跟元素 project 下的 dependencies 可以包含一个或者多个 dependency 元素,

    以声明一个或者多个项目依赖。每个依赖可以包含的元素有:

 

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8.1</version>
    <scope>test</scope>
</dependency>

 

    a) groupId、artifactId和version

           依赖的基本坐标,Maven根据坐标才能找到需要的依赖。

    b) type

           依赖的类型,对应项目坐标定义的packaging,默认值是jar,大部分情况下,

           该元素不必声明。

     c) scope

           依赖范围就是用来控制三种classpath(编译classpath、测试classpath、运行classpath)的关系。

           i.   compile

                编译依赖范围。如果没有指定,就会使用该默认依赖范围。此依赖范围对编译、

                测试、运行三种classpath都有效。例如:spring-core

           ii.   test

                测试依赖范围。只对于测试classpath有效。例如:Junit

           iii. provided

               已提供依赖范围。对于编译和测试classpath都有效,但在运行时无效。

               例如:servlet-api

          iv.  runtime

               运行时依赖范围。对于测试和运行classpath有效,但在编译主代码使无效。

               例如:JDBC驱动

          v.  system

               系统依赖范围。与classpath的关系和provided依赖范围完全一致。

               只是system范围的依赖必须通过systemPath元素显示的指定依赖文件路径。

               这类依赖不通过maven仓库解析,往往和本机系统绑定,

               可能造成构建的不可移植,应当谨慎使用。

          vi.  import

               导入依赖范围。不会对三种classpath产生实际的影响(暂且不管)。

Maven 坐标和依赖

    d) optional

           标记依赖是否可选。

           在理想的情况下,是不应该使用可选依赖的。使用可选依赖的原因是某一个项目实现可多个特性,

           在面向对象设计中,有个单一职责性原则,意指一个类应该只有一项职责,而不是柔和太多的功能。

           如:mySQL驱动、postgreSQL驱动。

     e) exclusions

          用来排除传递性依赖。

          传递性依赖会给项目隐式的引入很多依赖,这极大的简化了项目依赖的管理。

          但也会带来相应的问题。例如:SNAPSHOT版本的jar不稳定性。

          代码中使用exclusions元素声明排出依赖,可以包含一个或者多个exclusion子元素,

          所以可以排出一个或者多个传递性依赖。使用此元素只需要groupId和artifactId,

          而不需要version。

 

3. 传递性依赖

    如果项目里面的一个依赖,依赖于另外的依赖,那么这个另外的依赖,不需要你手动引入,

    也会自动依赖进来,就像传递的感觉一样。Maven 会解析各个直接依赖的 POM,

    将那些必要的间接依赖,以传递性依赖的形式引入到当前的项目中。

    例如:A -> B B -> C ==> A -> C

Maven 坐标和依赖
 

    a) 当第二依赖的范围是 compile 的时候,传递性依赖的范围与第一直接依赖的范围一致。

    b) 当第二直接依赖的范围是 test 的时候,依赖不会得以传递。

    c) 当第二依赖的范围是 provided 的时候,只传递第一直接依赖范围也为 provided的依赖,

          且传递性依赖的范围同样为 provided。

   d) 当第二直接依赖的范围是 runtime 的时候,传递性依赖的范围与第一直接依赖的范围一致,

         但 compile 例外,此时传递的依赖范围为 runtime。

 

4. 依赖调解

    传递性依赖机制,一方面大大简化和方便了依赖声明,另一方面,

    大部分情况我们只需要关心项目的直接依赖,而不考虑这些直接依赖会引入什么传递性依赖。

    不过有的时候,也会造成不小的问题。

    a) 调解第一原则:

           传递性依赖中,路径最近者优先。

    b) 调解第二原则:

           第一声明者优先。在依赖路径长度相等的前提下,

           在 POM 中依赖声明的顺序决定了谁会被解析使用,顺序最靠前的那个依赖优胜。

 

5. 最佳实践

    a) 排除依赖

          2. e)章节已讲。

    b) 归类依赖

          一类的依赖一起引入,一个项目不同的子模块。例如:spring-aop,spring-core。

    c) properties 定义 maven 属性

          properties 元素定义的属性,可以使用美元符号和大括弧环绕的方式引入 Maven属性。

          例如:${spring.version}

    d) 优化依赖

           i.   dependency:list

                显示已解析树。

           ii.  dependency:tree

                显示当前依赖树。

           iii. dependency:analyze

                分析当前项目的依赖。

                1) Use undeclared dependencies

                      项目使用到,但是没有显示声明的依赖,这意味着隐藏风险,

                      所以应该显示声明任何项目中直接用到的依赖。

                2) Use declared dependencies

                      项目中没有使用到,但是却显示声明的依赖。这类别的依赖,不能轻易删除声明,

                      应该仔细分析项目中是否有使用到。比如:analyze 指令只分析编译主代码和测试代码时

                      用到的依赖,一些执行测试和运行时需要的依赖发现不了。

 

 

你可能感兴趣的:(maven,依赖,坐标)