快速了解Maven核心概念和工程实践

Maven 是项目管理和构建工具。

说完是不是还是不知道Maven 做什么的？ 项目管理和构建听着比较虚，

举个栗子，我们alpha 电商项目中，分为订单、商品、商家、用户和营销模块，订单模块需要用到用户模块的代码，比如查询用户信息的接口，那是不是需要用户模块的同学把代码拷贝一份给订单模块呢？ 这么做会有很多问题，第一是用户模块同学写的代码可能有bug，需要修复，另外模块的功能一直在迭代，比如原来接口里面只有按照userId查询，增加了姓名查询、手机号查询，写完需要重新拷贝代码，效率很低，聪明的工程师们想到一个方法，把这些代码集中存储管理，用包+版本的方式，这个集中存储的地方叫仓库，大家都以仓库的为准，变更通过版本号来维护，为了防止每个小改动都需要修改版本，也是把线下用的测试版本和线上生产环境的区分开，分为Snapshot包和Release包。

总的来说，Maven 可以很方便的管理项目的结构和依赖关系。

在Maven 中，很重要的一个概念是仓库（Repository）。

maven仓库分为本地仓库和远程仓库。

远程仓库又包括私服和中央仓库。私服很好理解，很多公司自己会在局域网内搭建一个自己公司私有的仓库地址。

这里有个概念要区分一下，很多人会把私服和镜像（mirror）弄混，镜像（mirror）是中央仓库的复制品，原因也很简单，中央仓库在国外，你访问中央仓库的速度慢，镜像的服务器在国内，相当于弄了个缓存。

如果大家下载了maven，可以在maven 配置文件里面看下maven仓库的配置。下图是安琪拉电脑上的maven配置，一般放在用户目录.m2 文件夹下，setting.xml。

可以看到repository 是本地仓库文件夹，setting.xml 是maven 配置。

我们打开 settings.xml 看下。

          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  
  /${user.home}/.m2/repository
  true
  
  
  
    
      
      server001
      
      my_login
      
      my_password
      
      ${usr.home}/.ssh/id_dsa
      
      some_passphrase
    
  
 
   
        
        aliyunmaven
        
        central
        阿里云公共仓库
        https://maven.aliyun.com/repository/public
    
  
  
    
     
     aliyun
     
      
        
        false
         
        1.8
      
     
     
      
        aliyun
        aliyun
        http://maven.aliyun.com/nexus/content/groups/public/
        default
      
     
   
  
  
    aliyun
  

我们一项项解释：

    ${user.home}/our-project

那如果按照我们上面settings.xml 文件的配置，我们打包的时候maven 是如果查找包的呢?

maven 首先会先从本地仓库，也就是你自己电脑上查找包，如果没有，会从激活的profile的仓库查询，如果还没有找到，才会去中央仓库，如果你配置了中央仓库的镜像（mirror），这个时候就会被拦截，直接从镜像的仓库查找包。这个就是maven自动拉取包的流程。

小结：仓库分为本地仓库和远程仓库，本地仓库相当于按需拉取的包缓存，远程仓库分为中央仓库（central）和私服，私服一般是公司、学校或者其他团体为了加速包访问搭建的局域网的访问仓库，另外有些比较大的IT厂商，例如阿里云会搭建中央仓库的镜像，我们如果配置了中央仓库的镜像，那访问中央仓库的请求都会被重定向到镜像仓库。maven 仓库的自定义在 settings.xml 文件（分为系统目录和用户目录，一般建议用用户目录的），profile 可以设置不同的激活条件，配置对应的仓库。

下面介绍项目内的maven。

Maven 基于约定大于配置的原则，定义了一个标准的目录结构。如下所示：

我们标准的工程结构如下图所示：

alpha-mall
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   └── resources
│   └── test
│       ├── java
│       └── resources
└── target

alpha-mall 就是 ${basedir} 目录。剩下的对照表格看非常清楚。

还记得我们之前说的properties 属性吗，basedir就是maven 项目中默认的properties。

POM( Project Object Model，项目对象模型 ) 是 Maven 工程的基本工作单元，是一个XML文件，包含了项目的基本信息，用于描述项目如何构建，声明项目依赖，等等。

在创建 POM 之前，我们首先需要描述项目组 (groupId), 项目的唯一ID。

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     
    4.0.0
    
    com.angela.alpha
    
    alpha-shoppingmall
    
    1.0-SNAPSHOT

所有 POM 文件都需要 project 元素和三个必需字段：groupId，artifactId，version。

依赖管理：

A 依赖B，B依赖C，A相当于也依赖到了C。

举个栗子：

我截了一张IDEA Maven Lifecycle的图

这些Lifecycle实际都是通过插件的形式来完成的，maven其实大功能都是通过插件来完成的。

我们现在来实践一个项目，我在之前文章介绍过，现在一般稍大一点的项目，都是采用多模块管理，如果引入了领域概念，一般分层还有领域层，那这样一个项目我们应该怎么设置maven 包结构呢。例如：

首先我们会在父项目中定义这些这个项目包含的模块

    
        alpha-mall-api
        alpha-mall-dao
        alpha-mall-manager
        alpha-mall-service
        alpha-mall-web
        start
    

接着是dependencyManagement, 这个在多模块项目里面非常重要。

dependencyManagement里配置并不会实际引入，只是为了版本管理。

整个项目用到的依赖包的版本都应该在父项目pom的dependencyManagement 这里来管理，这样版本不会乱，管理也集中。

    
        1.8
        UTF-8
        UTF-8
        2.4.1
        3.4.8
    

  
        
            
                org.springframework.boot
                spring-boot-dependencies
                ${spring-boot.version}
                pom
                import
            
            
                com.taobao.arthas
                arthas-spring-boot-starter
                ${arthas-spring-boot.version}
                jar
            
        
    

一般可以直接在 properties 里面把第三方包的版本定义好，比如Spring boot和 Spring cloud的版本。

另外大家注意到 spring-boot-dependencies 这个包我们 type 使用的是pom，也就是我们不真实需要引入 spring-boot-dependencies，这个包里面包含的jar 基本涵盖了Spring 全家桶，已经Spring 和其他匹配的第三方中间件，pom的意思是我们只需要maven 包版本信息，这样有什么好处，比如你引入一个第三方包，担心用的版本和Spring 的版本不兼容，不用担心，Spring早就替你想好了，当你引入 spring-boot-dependencies ，他里面基本涵盖了市面上常用的组件，相对于的版本也都给你定义好了。截个图你看下：

另外一个属性是scope，也很重要。我们看下scope 的可选值：

重点：默认不配置都是compile属性。

compile ：默认值，compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。

provided ：在编译、测试时有效，但是在运行时无效。例如：servlet-api，运行项目时，Tomcat这种运行容器已经提供，就不需要Maven重复地引入一遍了。

runtime ：在运行、测试时有效，但是在编译代码时无效。例如：JDBC驱动实现，项目代码编译只需要JDK提供的JDBC接口，只有在测试或运行项目时才需要实现上述接口的具体JDBC驱动。

test ：只在测试时有效，例如：JUnit。

system ：在编译、测试时有效，但是在运行时无效。和provided的区别是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

scope的依赖传递 A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是： 当C是test或者provided时，C直接被丢弃，A不依赖C； 否则A依赖C，C的scope继承于B的scope。

好了，最后我们再选一个子模块的maven包看看，配置如下：

在start 启动模块，我们来看下：

    //定义父模块，relativePath 相对路径表明父模块就在上一层
  
        com.angela.alpha
        alpha-mall
        0.0.1-SNAPSHOT
        ../pom.xml
    

   
      org.mybatis.spring.boot
      mybatis-spring-boot-starter
  

    
      com.taobao.arthas
      arthas-spring-boot-starter
      runtime
    

可以看到包依赖是不带版本号的，因为所有的版本号都是父模块统一定义，这样也能减少包版本不一致，一个项目存在多个版本的情况。

  
    org.springframework.boot
    spring-boot-starter-test
    test
    
      
        org.junit.vintage
        junit-vintage-engine
      
    
  

另外我们经常会看到 exclusion，这个在解决包冲突的时候很有效。

先说包冲突的原因，比如

但是B和D 引入的C 的版本不一致，编译的时候会报错，这个时候要确定报错的代码使用的哪个版本，常规原则是用新版本，因为大部分时候第三方包升级会考虑兼容，不会直接把原来的版本给覆盖，但是也有特殊情况，这个就得具体case 具体分析了。

我们可以借助Maven Helper插件中的Dependency Analyzer分析冲突的jar包。

因为篇幅原因，关于Maven 的介绍先到这里，希望大家看完有收获。