一. 創建單獨的根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中更新版本即可對外發版.