1. 聚合

父pom配置

//这三行和其他构件一样

<artifactId>yyy</artifactId>

<groupId>xxxx</groupId>

<version>1.0.0</version>

//父工程的packing必须是pom

<packaging>pom</packaging>

//子模块，已经在父工程中声明任意多个module

<modules>

    //每个module的值都是相对父pom文件的相对目录，可以不一致！例如dao放在testdao目录下，那么module的值改为testdao

    <module>provider</module>   

    <module>task</module>

    <module>biz</module>

    <module>service</module>

    <module>domain</module>

    <module>dao</module>

    <module>common</module>

</modules>

聚合模块(父工程)和其他模块的目录结构并非一定要是父子关系，可以是平行关系，无论放哪里，只要module的值对应起来即可，永远记着相对于聚合模块的pom文件位置

mvn clean install后，maven会首先解析模块的pom，分析要构建的模块，并计算出一个反应堆构建顺序，然后根据这个顺序依次构建各个模块，反应堆是所有模块组成的一个构建结构

 

2. 继承

可以复用配置，在父pom中统一管理公共配置

可以继承的元素

  • groupId:项目组id，项目坐标的核心元素
  • version：项目版本，项目坐标的核心元素
  • description：项目的描述信息
  • organization：项目的组织信息
  • inceptionYear：项目的创始年份
  • url：项目的url
  • developers：项目开发者信息
  • contributors：项目的贡献者信息
  • distributionManagement：项目的部署设置
  • issueManagement：项目的缺陷跟踪系统信息
  • ciManagement：项目的持续集成系统信息
  • scm：项目的版本控制系统信息
  • mailingLists：项目的邮件列表信息
  • properties：自定义的maven信息
  • dependencies：项目的依赖配置
  • dependencyManagement：项目的依赖管理配置
  • repositories：项目的仓库配置
  • build：包括项目的源码目录配置，输出目录配置，插件配置，插件管理配置等
  • reporting：包括项目的报告输出目录配置，报告插件配置等

 

2.1. 依赖管理

dependencyManagement用这个元素定义依赖管理，主要做声明使用，子模块再去具体的使用

Maven---dependencies与dependencyManagement的区别

import的依赖范围，这个依赖范围在dependencyManagement元素下才有意义，使用该范围的依赖通常执行一个pom，作用是将目标pom中的dependencyManagement配置导入合并到当前pom的dependencyManagement元素中

示例：

配置

<dependencyManagement>

    <dependencies>   

        //代表会把这个外界的pom导入本pom合并dependencyManagement

        <dependency>

            <groupId>xxxxx</groupId>

            <artifactId>xxxx</artifactId>

            <version>1.0.0</version>

            <type>pom</type>

            <scope>import</scope>

        </dependency>

    </dependencies>

</dependencyManagement>

 

2.2. 插件管理

pluginManagement和dependencyManagement一样，原理同上

 

3. 聚合与继承的关系

聚合：为了方便快速构建多个项目

继承：主要为了消除重复配置

对于聚合模块来说，它知道有哪些被聚合的模块，但是被聚合的模块不知道有这个聚合模块

对于继承关系的父pom来说，它不知道有哪些子模块继承于它，但哪些子模块都必须知道自己的父pom是什么

两个共同点在于packaging都是pom，同时聚合模块和继承关系的父模块除了pom之外都没有实际内容

所以在实际项目中，一个pom既是聚合又是父pom，这样主要为了方便，聚合模块和继承糅合在一起

 

4. 约定优于配置

准守约定可以减少配置

maven默认的约定

  • 源码目录：src/main/java
  • 编译输出目录：target/classes
  • 打包方式:jar
  • 包输出目录为：target/

如果需要自己定义也可以，在build下使用sourceDirectory改变源码目录

在maven的超级pom中，定义了中央仓库，默认的插件仓库，定义好了默认的目录结构，定义好了默认的插件版本。

配置

<project>

    <modelVersion>4.0.0</modelVersion>

    <artifactId>sdsad</artifactId>

    <groupId>ttt</groupId>

    <version>1.0.0</version>

    <packaging>jar</packaging>

</project>

意味着我们只需要写上面一些配置就可以完成一个项目的配置，这就是约定的强大之处，大大减少配置量

 

 

5. 反应堆

在一个多模块的maven项目中，反应堆是指所有模块组成的一个构建结构，对于单模块的项目，反应堆是该模块本身，但是对于多模块来说，反应堆就包含量各模块之间继承与依赖的关系，从而能够自动计算出合理的模块构建顺序

构建顺序：

maven按顺序读取pom，首先是聚合pom，然后是按modules中的顺序。

如果该pom没有依赖就构建，然后按顺序往下继续构建其他，如果该pom有依赖，那么先构建其依赖，如果该依赖还有依赖就继续先构建依赖的依赖

 

模块之间的依赖关系会将反应堆构成一个有向非循环图，各个模块就是该图节点，依赖关系构成量有向边，这个图不能出现循环，否则报错

 

一般来说，用户会选择构建整个项目或者选择构建单个模块，但有些时候，用户会想仅仅构建完整反应堆中的某些模块，换句话说用户需要实时地剪裁反应堆

  • -am   同时构建所列模块的依赖模块
  • -amd  同时构建依赖于所列模块的模块
  • -pl  指定构建的模块，模块用逗号分割
  • -rf  从指定的模块回复反应堆,也就是从指定的模块开始继续往下构建，之前的反应堆就剪裁掉了