基于maven中多个⼦模块的构建顺序
⽬录
maven多个⼦模块的构建顺序
这是因为⼦模块的构建顺序受两个因素影响
实际的构建顺序是这样形成的
maven中的构建
1.什么是构建
2.构建过程的⼏个主要环节
3.⾃动化构建
maven多个⼦模块的构建顺序
在实际的项⽬开发中，为了更好的组织项⽬代码，会采⽤分层架构的⽅式，这就会使⽤到maven的多模块特性。
假设项⽬分为A、B、C、D四层，在⽗模块的l中，⼀般这样来对⼦模块进⾏聚合
<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 包部署到服务器上运⾏。
maven打包本地jar包
3.⾃动化构建
其实上述环节我们在 Eclipse 中都可以到对应的操作，只是不太标准。那么既然 IDE 已经可以进⾏构建了我们为什么还要使⽤ Maven 这样的构建⼯具呢？
我们来看⼀个⼩故事了解⼀下：
这是阳光明媚的⼀天。托马斯向往常⼀样早早的来到了公司，冲好⼀杯咖啡，进⼊了⾃⼰的邮箱——很不幸，QA ⼩组发来了⼀封邮件，报告了他昨天提交的模块的测试结果——有 BUG。“好吧，反正也不是第⼀次”，托马斯摇摇头，进⼊ IDE，运⾏⾃⼰的程序，编译、打包、部署到服务器上，然后按照邮件中的操作路径进⾏测试。“嗯，没错，这个地⽅确实有问题”，托马斯说道。于是托马斯开始尝试修复这个 BUG，当他差不多有眉⽬的时候已经到了午饭时间。下午继续⼯作。BUG 很快被修正了，接着托马斯对模块重新进⾏了编译、打包、部署，测试之后确认没有问题了，回复了 QA ⼩组的邮件。⼀天就这样过去了，明媚的阳光化作了美丽的晚霞，托马斯却觉得⽣活并不像晚霞那样美好啊。
让我们来梳理⼀下托马斯这⼀天中的⼯作内容
从中我们发现，托马斯的很⼤⼀部分时间花在了“编译、打包、部署、测试”这些程式化的⼯作上⾯，⽽真正需要由“⼈”的智慧实现的分析问题和编码却只占了很少⼀部分。
能否将这些程式化的⼯作交给机器⾃动完成呢？——当然可以！这就是⾃动化构建。
此时 Maven 的意义就体现出来了，它可以⾃动的从构建过程的起点⼀直执⾏到终点：
以上为个⼈经验，希望能给⼤家⼀个参考，也希望⼤家多多⽀持。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。