一. 创建单独的根pom 文件, root-pom, 工程中只有一个pom文件 文件中内容如下:
1. 各个依赖jar的版本, 即 dependencyManagement 内容
2. build 规定了 resource 及testResource的文件格式及目标文件夹
3. pluginManagement, 规定了各个插件的版本
4. distributionManagement, 规定了nexus私服
二. 创建项目文件项目MyProject, 包含三个模块
1. myproject-module, 主要用来存放需要被其他服务引用的model及enum类信息
2. myproject-api, 主要用来存放该服务的service接口
3. myproject-service, 主要用来实现该项目提供的服务是实际实现
于是,我在这个工程中, 得到4个pom文件,artifactId 依次为 myproject myproject-module myprojec-api myprojec-service,
pom继承关系:
最外层的 myproject 继承 root-pom, 且在 myproject中声明其工程的版本号, myproject-module myprojec-api myprojec-service 三个子模块中, 父pom为 myproject, 继承其groupId, 但是artifactId为模块单独所有, 子模块继承父pom的版本号, 子模块中使用到的具体的jar依赖及profile以及各种插件, 均继承父pom的版本依赖.
具体项目中使用spring-cloud作为服务治理框架,其中 api部分基于feign实现,实现单独jar的外发,实现服务的接口外漏, service中实现api中规定的接口, module中定义了对外暴露的各种类定义.
作出以上工程结构的原因:
1. 统一了各个jar的版本, 因工程实践中,一个service会集成多个api及module, 如果各个模块中以来的jar存在版本不一致, 将对最终的依赖版本产生困扰, 特别是在某些依赖jar出现安全问题,需要进行版本升级的时候.
2. 原有的依赖结构中,api独自继承拥有feign属性的pom, service独立继承拥有db 及 mvc 以及eureka-client属性的pom, 且各个pom最终继承自一个规定了版本及各种实际依赖的根pom,虽然简化了子pom中各种配置, 但是造成版本的依赖复杂难懂,加之maven的pom继承和版本的关系,导致版本升级繁琐,且存在潜在的jar冲突.
3. 由于api及module版本需要随着服务接口的更新而更新,所以各个子模块继承了工程的版本号, 如果接口出现更新,只需要在工程的pom中更新版本即可对外发版.
