基于maven中多个子模块的构建顺序

maven多个子模块的构建顺序

在实际的项目开发中，为了更好的组织项目代码，会采用分层架构的方式，这就会使用到maven的多模块特性。

假设项目分为a、b、c、d四层，在父模块的pom.xml中，一般这样来对子模块进行聚合

<modules>
    <module>a</module>
    <module>b</module>
    <module>c</module>
    <module>d</module>
</modules>

假设各个子模块间，配置的相互依赖关系如下：

a 依赖 b
b 依赖 c
d 依赖 a

构建父模块，我们能够看到以下输出：

[info] ------------------------------------------------------------------------
[info] reactor build order:
[info]
[info] c
[info] b
[info] a
[info] d
[info]
[info] ------------------------------------------------------------------------

这是因为子模块的构建顺序受两个因素影响

• 1、父模块中各子模块的声明次序
  
• 2、子模块间的依赖关系

实际的构建顺序是这样形成的

maven按照次序读取pom，如果该pom没有依赖其他子模块，就构建该模块，否则就构建其依赖的模块，如果该依赖模块还依赖于其他的模块，那么就进一步构建依赖的依赖。

在示例中，a模块依赖b，而b模块又依赖c，因此要先构建c，再构建b，然后才能构建a。而d依赖的模块a已经构建了，因此直接构建它。

模块间的依赖关系会将反应堆(reactor)构成一个有向非循环图，各个模块是该图的节点，依赖关系构成了有向边。这个图不允许出现循环。如果a依赖b，b又依赖a，这样就产生了循环依赖，maven会报错。

maven中的构建

1.什么是构建

构建并不是创建，创建一个工程并不等于构建一个项目。要了解构建的含义我们应该由浅入深的从 以下三个层面来看：

（1）纯 java 代码 （编译）

大家都知道，我们 java 是一门编译型语言，.java 扩展名的源文件需要编译成.class 扩展名的字节码 文件才能够执行。所以编写任何 java 代码想要执行的话就必须经过编译得到对应的.class 文件。

（2）web 工程 （部署）

当我们需要通过浏览器访问 java 程序时就必须将包含 java 程序的 web 工程编译的结果“拿”到服务 器上的指定目录下，并启动服务器才行。这个“拿”的过程我们叫部署。我们可以将未编译的 web 工程比喻为一只生的鸡，编译好的 web 工程是一只煮熟的鸡，编译部署 的过程就是将鸡炖熟。

注意： 开发过程中使用路径或配置文件中配置的类路径等都是以编译结果的文件结构为标准。

（3）实际项目

在实际项目中整合第三方框架，web 工程中除了 java 程序和 jsp 页面、图片等静态资源之外，还 包括第三方框架的 jar 包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服 务器上，项目才可以运行。

所以综上所述：构建就是以我们编写的 java 代码、框架配置文件、国际化等其他资源文件、jsp 页 面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。

2.构建过程的几个主要环节

• （1）清理：删除以前的编译结果，为重新编译做好准备。
• （2）编译：将 java 源程序编译为字节码文件。
• （3）测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
• （4）报告：在每一次测试后以标准的格式记录和展示测试结果。
• （5）打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。java 工程对应 jar 包，web 工程对应 war 包。
• （6）安装：在 maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中。
• （7）部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。

3.自动化构建

其实上述环节我们在 eclipse 中都可以找到对应的操作，只是不太标准。那么既然 ide 已经可以进 行构建了我们为什么还要使用 maven 这样的构建工具呢？

我们来看一个小故事了解一下：

这是阳光明媚的一天。托马斯向往常一样早早的来到了公司，冲好一杯咖啡，进入了自己的邮箱——很 不幸，qa 小组发来了一封邮件，报告了他昨天提交的模块的测试结果——有 bug。“好吧，反正也不是第一 次”，托马斯摇摇头，进入 ide，运行自己的程序，编译、打包、部署到服务器上，然后按照邮件中的操作 路径进行测试。“嗯，没错，这个地方确实有问题”，托马斯说道。于是托马斯开始尝试修复这个 bug，当他 差不多有眉目的时候已经到了午饭时间。 下午继续工作。bug 很快被修正了，接着托马斯对模块重新进行了编译、打包、部署，测试之后确认没 有问题了，回复了 qa 小组的邮件。 一天就这样过去了，明媚的阳光化作了美丽的晚霞，托马斯却觉得生活并不像晚霞那样美好啊。

让我们来梳理一下托马斯这一天中的工作内容

从中我们发现，托马斯的很大一部分时间花在了“编译、打包、部署、测试”这些程式化的工作上 面，而真正需要由“人”的智慧实现的分析问题和编码却只占了很少一部分。

能否将这些程式化的工作交给机器自动完成呢？——当然可以！这就是自动化构建。

此时 maven 的意义就体现出来了，它可以自动的从构建过程的起点一直执行到终点：

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。