\1. 【強制】定義 GAV 遵從以下規(guī)則:
1) GroupID 格式:com.{公司/BU }.業(yè)務線 [.子業(yè)務線]
,最多 4 級。
說明:{公司/BU}
例如:alibaba/taobao/tmall/aliexpress
等 BU 一級;子業(yè)務線可選。
正例:com.taobao.jstorm
或 com.alibaba.dubbo.register
2) ArtifactID 格式:產(chǎn)品線名-模塊名。語義不重復不遺漏,先到中央倉庫去查證一下。
正例:dubbo-client / fastjson-api / jstorm-tool
3) Version:詳細規(guī)定參考下方。
\2. 【強制】二方庫版本號命名方式:主版本號.次版本號.修訂號
1)主版本號:產(chǎn)品方向改變,或者大規(guī)模 API 不兼容,或者架構(gòu)不兼容升級。
2) 次版本號:保持相對兼容性,增加主要功能特性,影響范圍極小的 API 不兼容修改。
3) 修訂號:保持完全兼容性,修復 BUG、新增次要功能特性等。
說明:注意起始版本號必須為:1.0.0
,而不是 0.0.1
。
反例:倉庫內(nèi)某二方庫版本號從 1.0.0.0
開始,一直默默“升級”成 1.0.0.64
,完全失去版本的語義信息。
\3. 【強制】線上應用不要依賴 SNAPSHOT 版本(安全包除外);正式發(fā)布的類庫必須先去中央倉庫進行查證,使 RELEASE 版本號有延續(xù)性,且版本號不允許覆蓋升級。
說明:不依賴 SNAPSHOT 版本是保證應用發(fā)布的冪等性。另外,也可以加快編譯時的打包構(gòu)建。
\4. 【強制】二方庫的新增或升級,保持除功能點之外的其它 jar 包仲裁結(jié)果不變。如果有改變,必須明確評估和驗證。
說明:在升級時,進行 dependency:resolve
前后信息比對,如果仲裁結(jié)果完全不一致,那么通 dependency:tree
命令,找出差異點,進行<exclude>
排除 jar 包。
\5. 【強制】二方庫里可以定義枚舉類型,參數(shù)可以使用枚舉類型,但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象。
\6. 【強制】依賴于一個二方庫群時,必須定義一個統(tǒng)一的版本變量,避免版本號不一致。
說明:依賴 springframework-core,-context,-beans
,它們都是同一個版本,可以定義一個變量來保存版本:${spring.version}
,定義依賴的時候,引用該版本。
\7. 【強制】禁止在子項目的 pom 依賴中出現(xiàn)相同的 GroupId,相同的 ArtifactId,但是不同的Version。
說明:在本地調(diào)試時會使用各子項目指定的版本號,但是合并成一個 war,只能有一個版本號出現(xiàn)在最后的 lib 目錄中。曾經(jīng)出現(xiàn)過線下調(diào)試是正確的,發(fā)布到線上卻出故障的先例。
\8. 【推薦】底層基礎技術(shù)框架、核心數(shù)據(jù)管理平臺、或近硬件端系統(tǒng)謹慎引入第三方實現(xiàn)。
\9. 【推薦】所有 pom 文件中的依賴聲明放在<dependencies>
語句塊中,所有版本仲裁放在 <dependencyManagement>
語句塊中。
說明:<dependencyManagement>
里只是聲明版本,并不實現(xiàn)引入,因此子項目需要顯式的聲明依賴,version 和 scope 都讀取自父 pom。而<dependencies>
所有聲明在主 pom 的<dependencies>
里的依賴都會自動引入,并默認被所有的子項目繼承。
10.【推薦】二方庫不要有配置項,最低限度不要再增加配置項。
11.【推薦】不要使用不穩(wěn)定的工具包或者 Utils 類。
說明:不穩(wěn)定指的是提供方無法做到向下兼容,在編譯階段正常,但在運行時產(chǎn)生異常,因此,盡量使用業(yè)界穩(wěn)定的二方工具包。
12.【參考】為避免應用二方庫的依賴沖突問題,二方庫發(fā)布者應當遵循以下原則:
1)精簡可控原則。移除一切不必要的 API 和依賴,只包含 Service API、必要的領域模型對象、Utils 類、常量、枚舉等。如果依賴其它二方庫,盡量是 provided 引入,讓二方庫使用者去依賴具體版本號;無 log具體實現(xiàn),只依賴日志框架。
2)穩(wěn)定可追溯原則。每個版本的變化應該被記錄,二方庫由誰維護,源碼在哪里,都需要能方便查到。除非用戶主動升級版本,否則公共二方庫的行為不應該發(fā)生變化。
更多建議: