Maven百科 - 项目构建中的聚合与继承

摘要    

   继承和聚合看似都是在主要的POM文件中作一下相应的配置，在实际操做过程当中每每只是知其然不知其因此然，不知道的可能很容易混淆。

 

1 继承

    

    继承就是在从主pom那里继承许多重用的配置，能够省去许多代码量了。

使用继承方式的话，须要一个主POM，其packaging定义为pom。它自己能够不参与构建

<groupId>com.sd</groupId>
 <artifactId>sd.excel</artifactId>
 <packaging>pom</packaging>
 <version>1.0-SNAPSHOT</version>

    此外还须要在子模块中 定义父模块的相关信息。 

<parent>
        <artifactId>sd.excel</artifactId>
        <groupId>com.sd</groupId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>sd.excel.base</artifactId>
    <name>sd.excel.base</name>

    在parent元素中声明的是父pom的GAV和父POM的相对路劲。 而后再声明本身的GAV。 上图的group和version省略了，缘由是从主POM那里继承了。

   除了groupId和Version 还有哪些元素能够被继承的呢？

 1.1 可继承的POM元素

groupId	项目Id
version	项目版本
description	项目描述
organization	项目组织信息
inceptionYear	项目创始年份
url	项目url地址
developers	项目开发者
contributors	项目贡献者
distributionManagement	项目部署配置
issueManagement	项目缺陷跟踪系统信息
ciManagement	项目的持续集成系统信息
scm	项目的版本控制系统信息
mailingList	项目的邮件列表信息
properties	自定义的maven属性
dependencies	项目的依赖配置
dependenciesManagement	项目的依赖配置管理
repositories	项目仓库配置
build	项目的构建配置，包括源码，输出目录，插件配置等
reporting	报告配置

 

 

2. 聚合

    所谓聚合，其实就是多模块构建。面对较为复杂的项目，一般都会被分为不少相互依赖的模块，而这些模块是独立构建，maven为了应付这种相似的需求，设置了聚合方式。

    使用聚合方式，须要组建一个主模块或者说聚合模块，它是用来管理组织那些小模块。这个聚合模块自己是不用构建的，

它只须要定义一个看似较为特殊的POM便可。

    咱们以模块 account-email和account-persist为例，咱们为此组建了一个名为account-aggregator的聚合模块。聚合模块的POM长这样：

    

<modelVersion>4.0.0</modelVersion>

    <groupId>com.sd</groupId>
    <artifactId>sd.excel</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <modules>
        <module>sd-excel-api</module>
        <module>sd-excel-base</module>
    </modules>

    其中须要注意的地方是packaing 被定义为POM，其次它额外声明了 modules 在这里面 添加了各个module的名字。

固然了，这只是创建在 主POM文件和 各模块是父子层级关系的时候，固然也能够是平行关系。见下图

    左图是父子关系的层级图，右图是平行关系的层级图。若是说只用层级关系的时候主POM中的module须要作相应的变化、

    还有一点须要注意的是，各个被聚合模块不知道其余聚合模块的存在，若是模块之间有依赖关系，须要在本身的POM文件声明GAV。

    好在MAVEN会根据依赖关系，决定编译打包顺序。

3 DependencyManagement

    DependencyManagement 内部声名的依赖包 自己不会被项目引入， 若是项目使用的依赖包(包括隐形依赖，引入的一些包) 会优先从DependencyManagement里面查询对应的版本号，若是没有则使用默认传递依赖的版本号。 用来解决maven冲突是个很好的办法

如：在dependencyManagement 中定义了junit的版本和scope

<dependencyManagement>
     <dependencies>
            <!-- Testing -->
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>4.10</version>
                <scope>test</scope>
            </dependency>

        </dependencies>
    </dependencyManagement>

那么在其余地方,在使用junit的时候能够不用定义 version和scope， 另外对于一些传递依赖导进来的junit 也会使用dependencyManagement中定义的版本和scope。

<dependencies>
            <!-- Testing -->
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
            </dependency>
              

              <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-test</artifactId>
    <version>4.3.8.RELEASE</version>
       </dependency>

        </dependencies>