基建项目POM结构

无

parent

java.version等一些Maven内部的属性

pom管理的所有依赖包的版本都应该定义为properties，参考spring的顶层pom

properties

modules

profiles

profiles中会写明不同的环境下的不同构建方式，build中一般定义任何环境都需要的构建配置。毕竟在各个环境中都重复配置一遍是不优雅的。一般来说这部分我们可以沿用springboot的构建方式或者maven默认的构建方式。

build

dependencies

用于管理项目中可能用到的所有依赖，保证各个依赖之间是兼容的。值的注意的是，dependencyManagement仅仅是声明依赖，子模块需要用到某个依赖的时候，还是需要自己去引用，规范来说子模块中不需要也不允许定义明确的版本。dependencyManagement中已经声明了版本，只要子模块中依赖的包在dependencyManagement中存在就会沿用其版本。只有这样dependencyManagement解决各依赖包之间冲突的意义才能体现。

进阶：当依赖的包足够多的时候，因为maven只支持单继承，其导致的问题就是，当子模块足够多的情况下，顶层pom可能需要依赖大量的jar包，且这些jar包互相之间没有做边界管理的，即所有的jar包混在一起了。maven提供了scope:imort的模式，可以对pom文件的依赖进行拆分。其作用其实和dependencies中我们提供的按场景拆分思路相同，但效果上有区别。上面提到的是使用scope:pom，依赖这个pom就会把其内的所有依赖都依赖到项目中。而scope:imort仅仅是对其内的依赖进行声明。

延续上面第二点来讲，如果使用scope:import的话，其拆分场景可能就不是按业务场景进行拆分了。因为如果需要某个业务场景，那么该业务场景相关的包都依赖进来是合理的。但如果使用scope：import还按业务场景进行拆分的话，那么仅仅是对该业务场景所需要的包进行了一次全量的声明，子模块还需要自己引用一遍，这样拆分的话意义就不大了。所以scope:import一般用于管理同样功能的组件(可选型)，如所有的日志框架的管理我们可以定义一个pom进行统一声明。最终子模块只会用到其内的一个实现依赖，这时候其作用就体现在了同类型组件的统一管理上了。

dependencyManagement

统一定义好打包，编译，部署，测试等各个阶段的插件，子模块都可以继承这些插件的功能。

pluginManagement

定义了从哪个库地址下载项目依赖的库文件，注意repositories不仅仅是pom中生效，其是和本地的setting.xml文件(用户级别 系统级别)共同生效的，他们会做合并覆盖(同id覆盖)，pom中定义的优先级最高。一般来说在公司级别的pom，在这里定义一下公司的私人仓库地址，是合适的。但如果作为一个开源的组件，这里就无需做这种配置了。

repositories

定义了deploy时，包往哪个仓库发布。其生效规则和repositories一样。其使用场景也是repositories一样。对于公司级别的顶层pom，定义出distributionManagement是合适和合理的。

distributionManagement

主要用来声明所有的依赖

依赖的jar包的版本号，全部以properties的形式进行定义

就是定依赖的插件进行声明，未使用

静态配置层(最顶层)

主要定义一些动作，操作，打包时需要的配置

编译jdk版本，编码，字符编码等

如何打包的动作

插件的使用

动态配置层(第二层)

参考spirngboot的POM的设计

进阶

不要显示声明任何依赖的版本

用到什么包，就依赖什么包，不要打包依赖

除非特殊情况，无需自己定义打包插件，构建方式

子模块使用规范

顶层POM结构设计