基建项目POM结构

无

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

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

顶层pom,最好不要使用modules，modules一般用于打包时，会把子模块一起打包，一般适用于项目级别组件级别的顶层pom。而像spring或者是我们自己封装的顶层pom,这类pom一般用来对依赖的包的声明(避免冲突),定义打包环境，maven仓库等配置，对其来说，其对其下的所有子模块都应该是无感的，故不应该去配置modules。且如果配置modules的话，每次对pom的重新发布都需要保证子模块也在工作空间才行，而顶部pom应该是独立于所有子模块的。

用于打包时，区分不同的环境，一般来说这里我们会区分开发，测试，生产环境,不同的环境有不同的构建方式，不同的依赖，都可以在这里面进行配置。

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

顶层pom最好不要使用dependencies,否者会导致所有的子模块都依赖dependencies中定义的jar包,会导致子模块依赖到一些完全没有用到的jar包，使项目变的臃肿。我们来思考一下这样设计的出发点，显然是因为大多数的子模块都依赖到了这些包，子模块不想在自己的pom中去重复写一遍这些依赖了。事实上这种场景我们是有更好的方式去解决的。即收集某种使用广泛的场景下所需要依赖的所有包，再单独定义一个pom依赖所有这些包。这样如果某些子模块引用到了这个场景，那么只需要依赖这一个pom即可。这种业务场景的概念是略大于组件概念的，需要根据公司的技术选型进行个性化定制，一般囊括了多个开源组件，如springboot+mybatis+springmvc+日志这就是一个典型的场景。

用于管理项目中可能用到的所有依赖，保证各个依赖之间是兼容的。值的注意的是，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进行统一声明。最终子模块只会用到其内的一个实现依赖，这时候其作用就体现在了同类型组件的统一管理上了。

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

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

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

参考spirngboot的POM的设计

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

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

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