maven 为何要模块划分-聚合/继承

模块划分
为了防止传递依赖，我们各个模块之间尽量用直接依赖的方式。本篇文章介绍多模块化开发，我们做过Maven项目的都知道，我们的项目一般都是分模块的，每个模块都会对应着一个POM.xml文件，它们之间通过继承和聚合（也称多模块，multi-module）相互关联。

我们换另一种思路想想，那么我们能不能一个项目就用一个模块。这样开起来很方便，简单明了，那么做起来呢，接下来我们分析一下。

假设我们有这么一个项目，整个项目构建一个war包，而每一层放到各自的Package里面。如下：

Itoo-Exam

com.tgb.itoo.exam.dao —–负责与数据库的交互，封装了Hibernate的交互类

com.tgb.itoo.exam.service—-负责处理业务逻辑，放Service接口及其实现类

com.tgb.itoo.exam.web——-负责与客户端的交互，主要放action/controller，jsp等等

com.tgb.itoo.exam.util——–工具类

那么随着我们项目的扩大，Maven项目也会越来越大，那么会遇到下面的几个问题：

1、首先build整个项目的时间越来越长，尽管你一直在web层工作，但你不得不build整个项目

2、模块化体现不出来，如果我们只负责维护某个模块，因为我们所有的模块都在一个war包中，那么我们可以随意修改其他模块（权限的控制），导致版本管理混乱，冲突。同时因为模块太多，太大，不好维护。

很多人都在同时修改这个war包，将导致工作无法顺利进行。

3、pom.xml本来是可以继承、复用的，但是如果我们新建一个项目，只能依赖于这个war包，那么会把这个war包的相关的前台的东西依赖过来，导致项目管理混乱。

这样的管理是混乱的，没有遵守一个设计模式原则：“高内聚，低耦合”。相反在代码内部，所有的东西都耦合在了一起。因此我们需要划分模块。

另外，随着技术的飞速发展和各类用户对软件的要求越来越高，软件本身变得越来越复杂，设计人员开始采用各种方式进行开发，于是就有了我们的分层架构、分层模块来提高代码的清晰和重用。从而实现了系统内部的高内聚、低耦合。

实际上我们项目的包结构：

Itoo-root (pom.xml pom包)Itoo-base-parent(pom.xml pom包)Itoo-base（pom.xmljar包）Itoo-tool（pom.xmljar包）Itoo-exam-parent (pom.xml pom包)Itoo-exam-api        (pom.xml jar包)Itoo-exam-student-core  (pom.xml jar包)Itoo-exam-student-web  (pom.xml war包)Itoo-exam-student-ear   (pom.xml ear包)

如上关系图，pom包的全是父项目，用来管理子项目的jar包。parent里面聚合了很多子项目。

模块的依赖关系：

Itoo-base—>itoo-tool

Itoo-exam-api–>itoo-base

Itoo-exam-student-core—>itoo-exam-api

Itoo-exam-student-web—>itoo-exam-api

模块化的好处

1、方便重用，当我们再开发一条teacher线的时候，我们只需要引用itoo-base,itoo-exam-api，这些包都是复用的，称为我们平台复用的基础类库，供所有的项目使用。这是模块化最重要的一个目的。

3、灵活性。比如我们这些公共的jar包，itoo-base,itoo-tool,itoo-exam-api等这些jar包，我们不需要再当源码，只需要deploy到nexus，其他人从nexus下载即可。代码的可维护性、可扩展性好，并且保证了项目独立性与完整性。

5、上篇文章写得DependencyManagement与dependencies，父项目中管理jar包版本。使得整个项目的测试版本与发布版本一致。

使用模块化配置，复用性强，防止pom变得过于庞大，方便构建；针对项目的管理更方便，每一个模块都是独立的，抽象出一个父类来管理第三方jar的版本，开发人员只需要开发自己的线，其他的都不用管，灵活；基于此种基础我们还可以做分布式。

上面提到了我们用父项目聚合子项目，子项目继承父项目。下篇博客我们继续介绍Maven模块的聚合和继承。

模块聚合和继承
类之间有聚合和继承关系，Maven也具备这样的设计原则。那么Maven的pom是如何进行聚合与继承的呢？

一、什么是聚合？为什么要用聚合？

上一篇博客介绍了模块化的基本知识。有了模块化，那么我们项目中会有很多模块，每个模块都是独立的maven project，如果项目不大，我们还可以独立的编译测试运行每个模块，但是随着项目越来越大，我们不得不想办法让我们的工作变得简单，这时就出现了Maven聚合的方式来完成编译所有模块。

聚合：把多个模块或项目聚合到一期，我们可以建立一个专门负责聚合工作的project.
Maven聚合：当我们的模块非常多的时候，我们想要一次构建多个项目，而不是到多个模块的目录下分别执行命令。Maven的聚合特性就是为该需求服务的。

Pom.xml：
[java] view plaincopyprint

        <parent>              <groupId>com.tgb</groupId>              <artifactId>itoo-root</artifactId>              <version>0.0.1-SNAPSHOT</version>              <!-- 继承itoo-root的pom文件 -->              <relativePath>../itoo-root/pom.xml</relativePath>          </parent>          <artifactId>itoo-basic-parent</artifactId>          <packaging>pom</packaging>          <modules>              <module>../itoo-basic-api</module>              <module>../itoo-basic-institution-core</module>              <module>../itoo-basic-institution-web</module>              <module>../itoo-basic-institution-ear</module>          </modules>  

Maven约定：

1、首先聚合模块必须为pom，否则无法构建

2、必须有元素，它是实现聚合的最核心配置。这里可以声明多个module元素。每个module的值都是一个当前pom的相对目录。模块所处的目录必须和模块所处的目录一致。

3、为了方便用户构建项目，通常将聚合模块放在项目目录的最顶层，其他模块则作为聚合模块的子目录存在。

4、聚合模块的pom没有实质性内容，只有一个pom.xml文件。只是用来帮助其他模块构建的工具。

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

二、继承
Maven继承也是为了防止重复，让项目的jar包版本一致，在项目管理上起了很大的作用。

比如说相同的jar包我们每个人都需要依赖一遍，并且每个人引用的版本号不同，势必造成项目混乱，运行出问题。

1、子模块省略grouopId和version，都会从父模块依赖下来。

2、子模块元素pom.xml：

 <parent>              <groupId>com.tgb</groupId>              <artifactId>itoo-root</artifactId>              <version>0.0.1-SNAPSHOT</version>              <!-- 继承itoo-root的pom文件 -->              <relativePath>../itoo-root/pom.xml</relativePath>          </parent>  

三、总结

对于聚合模块来说，它知道有哪些被聚合的模块，而对于被聚合的模块来说，它们不知道被谁聚合了，也不知道它的存在；对于继承关系的pom来说，它不知道被哪些模块继承了，对于子pom来说，它必须知道要继承谁。

总之，聚合是为了方便快速构建项目，继承是为了消除重复配置，在简化pom的同时还能促进各个模块配置的一致性。共同点是两者的packaging都是pom，聚合模块与继承关系中的父模块除了pom之外都没有实际内容。

实际项目中我们会发现，一个pom既是聚合pom，也是父pom，这么做主要是为了方便。

Java成功的重要原因之一就是他能够屏蔽大部分操作系统的差异，XML流行的原因之一是所有语言都接受他。Maven用的人越来越所有用Maven管理的真实的项目都应该是分模块的，每个模块都对应着一个pom.xml。它们之间通过继承和聚合（也称作多模块，multi-module）相互关联。那么，为什么要这么做呢？我们明明在开发一个项目，划分模块后，导入Eclipse变成了N个项目，这会带来复杂度，给开发带来不便。

为了解释原因，假设有这样一个项目，很常见的Java Web应用。在这个应用中，我们分了几层：

Dao层负责数据库交互，封装了Hibernate交互的类。Service层处理业务逻辑，放一些Service接口和实现相关的Bean。Web层负责与客户端交互，主要有一些Structs的Action类。

对应的，在一个项目中，我们会看到一些包名：

org.myorg.app.daoorg.myorg.app.serviceorg.myorg.app.weborg.myorg.app.util

这样整个项目的框架就清晰了，但随着项目的进行，你可能会遇到如下问题：
这个应用可能需要有一个前台和一个后台管理端（web或者swing），你发现大部分dao，一些service，和大部分util是在两个应用中可。这样的问题，你一周内遇到了好几次。
pom.xml中的依赖列表越来越长以重用的，但是，由于目前只有一个项目（WAR），你不得不新建一个项目依赖这个WAR，这变得非常的恶心，因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，而且你根本不需要org.myorg.app.web。有人修改了dao，提交到svn并且不小心导致build失败了，你在编写service的代码，发现编译不过，只能等那人把dao修复了，你才能继续进行，很多人都在修改，到后来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引入。甚至出现了一个依赖有多个版本存在。
build整个项目的时间越来越长，尽管你只是一直在web层工作，但你不得不build整个项目。
某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。

我们会发现，其实这里实际上没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用Maven划分模块。

一个简单的Maven模块结构是这样的：—- app-parent

      |-- pom.xml (pom)         |         |-- app-util         |        |-- pom.xml (jar)         |         |-- app-dao         |        |-- pom.xml (jar)         |         |-- app-service         |        |-- pom.xml (jar)         |         |-- app-web                  |-- pom.xml (war)   

单示意图中，有一个父项目(app-parent)聚合很多子项目（app-util, app-dao, app-service, app-web）。每个项目，不管是父子，都含有一个pom.xml文件。而且要注意的是，小括号中标出了每个项目的打包类型。父项目是pom,也只能是pom。子项目有jar，或者war。根据它包含的内容具体考虑。

这些模块的依赖关系如下：

app-dao      --> app-utilapp-service --> app-daoapp-web     --> app-service

注意依赖的传递性（大部分情况是传递的，除非你配置了特殊的依赖scope），app-dao依赖于app-util，app-service依赖于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。

用项目层次的划分替代包层次的划分能给我们带来如下好处：

方便重用，如果你有一个新的swing项目需要用到app-dao和app-service，添加对它们的依赖即可，你不再需要去依赖一个WAR。而有些模块，如app-util，完全可以渐渐进化成公司的一份基础工具类库，供所有项目使用。这是模块化最重要的一个目的。
由于你现在划分了模块，每个模块的配置都在各自的pom.xml里，不用再到一个混乱的纷繁复杂的总的POM中寻找自己的配置。
如果你只是在app-dao上工作，你不再需要build整个项目，只要在app-dao目录运行mvn命令进行build即可，这样可以节省时间，尤其是当项目越来越复杂，build越来越耗时后。
某些模块，如app-util被所有人依赖，但你不想给所有人修改，现在你完全可以从这个项目结构出来，做成另外一个项目，svn只给特定的人访问，但仍提供jar给别人使用。
多模块的Maven项目结构支持一些Maven的更有趣的特性（如DepencencyManagement），这留作以后讨论。

接下来讨论一下POM配置细节，实际上非常简单，先看app-parent的pom.xml：多是Maven提倡约定优于配置，这是Maven最核心的设计理念之一。

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">          <modelVersion>4.0.0</modelVersion>          <groupId>org.myorg.myapp</groupId>          <artifactId>app-parent</artifactId>          <packaging>pom</packaging>          <version>1.0-SNAPSHOT</version>          <modules>              <module>app-util</module>              <module>app-dao</module>              <module>app-service</module>              <module>app-web</module>          </modules>      </project>  

Maven的坐标GAV（groupId, artifactId, version）在这里进行配置，这些都是必须的。特殊的地方在于，这里的packaging为pom。所有带有子模块的项目的packaging都为pom。packaging如果不进行配置，它的默认值是jar，代表Maven会将项目打成一个jar包。

该配置重要的地方在于modules，例子中包含的子模块有app-util, app-dao, app-service, app-war。在Maven build app-parent的时候，它会根据子模块的相互依赖关系整理一个build顺序，然后依次build。

这就是一个父模块大概需要的配置，接下来看一下子模块符合配置继承父模块。

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">          <parent>              <artifactId>app-parent</artifactId>              <groupId>org.myorg.myapp</groupId>              <version>1.0-SNAPSHOT</version>          </parent>          <modelVersion>4.0.0</modelVersion>          <artifactId>app-util</artifactId>          <dependencies>              <dependency>                  <groupId>commons-lang</groupId>                  <artifactId>commons-lang</artifactId>                  <version>2.4</version>              </dependency>          </dependencies>      </project>  

app-util模块继承了app-parent父模块，因此这个POM的一开始就声明了对app-parent的引用，该引用是通过Maven坐标GAV实现的。而关于项目app-util本身，它却没有声明完整GAV，这里我们只看到了artifactId。这个POM并没有错，groupId和version默认从父模块继承了。实际上子模块从父模块继承一切东西，包括依赖，插件配置等等。

此外app-util配置了一个对于commons-lang的简单依赖，这是最简单的依赖配置形式。大部分情况，也是通过GAV引用的。

再看一下app-dao，它也是继承于app-parent，同时依赖于app-util：

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">          <parent>              <artifactId>app-parent</artifactId>              <groupId>org.myorg.myapp</groupId>              <version>1.0-SNAPSHOT</version>          </parent>          <modelVersion>4.0.0</modelVersion>          <artifactId>app-dao</artifactId>          <dependencies>              <dependency>                  <groupId>org.myorg.myapp</groupId>                  <artifactId>app-util</artifactId>                  <version>${project.version}</version>              </dependency>          </dependencies>      </project>  

该配置和app-util的配置几乎没什么差别，不同的地方在于，依赖变化了，app-dao依赖于app-util。这里要注意的是version的值为${project.version}，这个值是一个属性引用，指向了POM的project/version的值，也就是这个POM对应的version。由于app-dao的version继承于app-parent，因此它的值就是1.0-SNAPSHOT。而app-util也继承了这个值，因此在所有这些项目中，我们做到了保持版本一致。

这里还需要注意的是，app-dao依赖于app-util，而app-util又依赖于commons-lang，根据传递性，app-dao也拥有了对于commons-lang的依赖。

app-service我们跳过不谈，它依赖于app-dao。我们最后看一下app-web：

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">          <parent>              <artifactId>app-parent</artifactId>              <groupId>org.myorg.myapp</groupId>              <version>1.0-SNAPSHOT</version>          </parent>          <modelVersion>4.0.0</modelVersion>          <artifactId>app-web</artifactId>          <packaging>war</packaging>          <dependencies>              <dependency>                  <groupId>org.myorg.myapp</groupId>                  <artifactId>app-service</artifactId>                  <version>${project.version}</version>              </dependency>          </dependencies>      </project>  

app-web依赖于app-service，因此配置了对其的依赖。

由于app-web是我们最终要部署的应用，因此它的packaging是war。为此，你需要有一个目录src/main/webapp。并在这个目录下拥有web应用需要的文件，如/WEB-INF/web.xml。没有web.xml，Maven会报告build失败，此外你可能还会有这样一些子目录：/js, /img, /css … 。

看看Maven是如何build整个项目的，我们在 app-parent 根目录中运行 mvn clean install ，输出的末尾会有大致这样的内容：

…

…

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[app-web] in [/home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in[50 msecs]
[INFO] Building war: /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war to /home/juven/.m2/repository/org/myorg/myapp/app-web/1.0-SNAPSHOT/app-web-1.0-SNAPSHOT.war
[INFO]
[INFO]
[INFO] ————————————————————————
[INFO] Reactor Summary:
[INFO] ————————————————————————
[INFO] app-parent …………………………………….. SUCCESS [1.191s]
[INFO] app-util ………………………………………. SUCCESS [1.274s]
[INFO] app-dao ……………………………………….. SUCCESS [0.583s]
[INFO] app-service ……………………………………. SUCCESS [0.593s]
[INFO] app-web ……………………………………….. SUCCESS [0.976s]
[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————
[INFO] Total time: 4 seconds
[INFO] Finished at: Sat Dec 27 08:20:18 PST 2008
[INFO] Final Memory: 3M/17M
[INFO] ————————————————————————

注意Reactor Summary，整个项目根据我们希望的顺序进行build。Maven根据我们的依赖配置，智能的安排了顺序，app-util, app-dao, app-service, app-web。

最后，你可以在 app-web/target 目录下找到文件 app-web-1.0-SNAPSHOT.war ，打开这个war包，在 /WEB-INF/lib 目录看到了 commons-lang-2.4.jar，以及对应的app-util, app-dao, app-service 的jar包。Maven自动帮你处理了打包的事情，并且根据你的依赖配置帮你引入了相应的jar文件。

使用多模块的Maven配置，可以帮助项目划分模块，鼓励重用，防止POM变得过于庞大，方便某个模块的构建，而不用每次都构建整个项目，并且使得针对某个模块的特殊控制更为方便。本文同时给出了一个实际的配置样例，展示了如何使用Maven配置多模块项目。