maven深入理解

maven 标签概览

scope 依赖范围

maven 中为我们提供了三种classpath:编译,测试,运行。依赖范围是控制依赖和三种classpath之间的关系

complie
默认的scope,在编译测试运行都有效。maven会将其打包到最终的artifact中。
provided
在测试和编译时候有效。这个scope假定对应的依赖由运行这个应该的JDK或者容器来提供。比如servelet Api。在最后的运行时不必加入，因为在运行时候由tomcat等容器提供。
runtime
在测试和运行时有效,比如JDBC API,在编译时候并不知道链接哪种数据库类型。在真正运行时候需要使用对应驱动比如mysql来操作对应的数据库。这个驱动也会最终被打包到artifact中
test
只是在测试阶段有效比如junit
system
和provided相似。唯一区别是system和本机系统相关联，可移植性差
import
只使用在dependencyManagement标签中，表示从其他的pom中导入dependency的配置。

依赖传递

比如有以下依赖 A->B->C
这里我们在A模块中配置


    com.B
    B
    1.0

这里我们在A中或自动导入C的包

exclusions

上述示例中我们看到传递依赖的特性,我们需要排除A模块中对C模块的依赖。

optional

optional作用和exclusions类似都是用来排除jar包依赖使用的。还是上面的例子：A->B-C。
假设我们在B中引入C包的时候设置optional为true


    com.C
    C
    1.0
    true

默认在A中不会将C的包引入,除非手动引入C包

dependencyManagement

dependencyManagement里只声明依赖，并不实现引入。因此自项目中需要显示声明需要用到的依赖

坐标规划

groupId 用来定义项目, artifactId用来定义模块。
比如公司网站为zoo.com,这里我们定义groupId 为com.zoo其实是不正确的，因为一个公司可能会有多个项目。这里可以定义groupId 为 com.zoo.dog
artifactId的定义也有最佳实践,我们看到一个项目中有很多模块，比如api,dao,service,web等。最终maven生成的构建不会带有groupId信息。会造成dog项目下有api.1.0.jar,cat项目下也有api.1.0.jar放在一起的时候回让混混淆。为了让坐标更加清晰，在定义artiafctId时加入项目的信息。比如dog项目中api模块，使用artifactId为dog-api.其他的为dog-dao,dao-service等

多模块

为什么dependencyManagement 只会影响现有依赖的配置，但不会引入依赖
为什么maven这样设计?假设多模块工程中有A,B,C三个模块。其中A和B需要依赖于common-io模块,C模块不需要。如果dependencyManagement直接导入的话，C模块中也会加载common-io这样包的大小就会膨胀，显然是不可以接受的。
在使用dependencyManagement时候，不从模块中继承
maven和Java一样是无法实现多重继承，如果10个20个甚至更多模块继承同一个模块，那么这个父模块的dependencyManagement会包含大量的依赖。这样父模块pom依赖就很不清晰。import scope 依赖能解决这个问题。父模块的pom会非常的干净

定义pom文件


  4.0.0
  com.juvenxu.sample
  sample-dependency-infrastructure
  pom
  1.0-SNAPSHOT
  
    
        
          junit
          junit
          4.8.2
          test
        
        
          log4j
          log4j
          1.2.16

父模块中通过scope import 引入这段依赖管理配置


    
        
          com.juvenxu.sample
          sample-dependency-infrastructure
          1.0-SNAPSHOT
          pom
          import