二方庫規約

1. 【強制】定義 GAV 遵從以下規則：

1 ) G GroupID 格式： com .{公司/ BU }.業務線. [ 子業務線 ] ，最多 4 級。

說明：{公司/ BU } 例如： alibaba / taobao / tmall / aliexpress 等 BU 一級 ；子業務線可選。

正例： com . taobao . jstorm 或  com.alibaba.dubbo.register 

2 ） A ArtifactID 格式：產品線名稱-模組名稱。語意不重複不遺漏，先到倉庫中心去查證。

正例： dubbo - client /  fastjson - api /  jstorm - tool

3 ） V Version ：詳細規定參考下方。

2. 【強制】二方庫版本號命名方式：主版本號.次版本號.修訂號

1 ） 主版本號主版本號：當做了不相容的API 修改，或增加了能改變產品方向的新功能。

2 ） 次版本號 次版本號：當做了向下相容的功能性新增 （ 新增類別、介面等 ） 。

3 ） 修訂號 修訂號：修正 bug ，沒有修改方法簽章的功能加強，保持  API 相容性。

說明：起始版本號碼必須為： 1.0.0 ，而不是0.0.1

3. 【強制】線上應用不要依賴SNAPSHOT版本（ 安全包除外）； 正式發布的類別庫必須使用RELEASE版本號升級1 的方式，且版本號不允許覆蓋升級，必須去中央倉庫進行查證。

說明：不依賴 SNAPSHOT 版本是保證應用程式發布的冪等性。另外，也可以加快編譯時的打包建置。

4. 【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變，必須明確評估和驗證，建議進行dependency : resolve 前後信息比對，如果仲裁結果完全不一致，那麼通過dependency : tree 命令，找出差異點，進行< excludes >排除jar 包。

5. 【強制】二方庫裡可以定義枚舉類型，參數可以使用枚舉類型，但是介面回傳值不允許使用枚舉舉型別或包含枚舉類型的POJO 物件。

6. 【強制】依賴一個二方庫群時，必須定義一個統一版本變量，避免版本號不一致。

說明：依賴springframework - core ,- context ,- beans ，它們都是同一個版本，可以定義一個個變數來保存版本：${ spring . version }，定義依賴的時候，引用該版本。

7. 【強制】禁止在子項目的 pom 依賴中出現相同的 GroupId ，相同的 ArtifactId ，但是不同的Version 。

說明：在本地偵錯時會使用各子項目指定的版本號，但合併成一個 war ，只能有一個版本號出現在最後的 lib 目錄中。曾經出現過線下調試是正確的，發佈到線上出故障的先例。

8. 【建議】所有pom 檔案中的依賴宣告放在< dependencies >語句區塊中，所有版本仲裁放在< ; dependencyManagement >語句塊中。

說明：< dependencyManagement >裡只是聲明版本，並不實現引入，因此子項目需要明確的聲音明依賴， version 和 scope 都讀取自父 pom 。而< dependencies >所有聲明在主 pom 的< dependencies >裡的依賴都會自動引入，並默認被所有的子項目繼承。

9. 【建議】二方函式庫盡量不要有配置項，最低限度不要再增加配置項。

10. 【參考】為避免應用二方函式庫的依賴衝突問題，二方函式庫發布者應遵循下列原則：

1 ） 精簡可控原則。移除一切不必要的 API 和依賴，只包含  Service API 、必要的領域模型對

象、 Utils 類別、常數、枚舉等。如果依賴其它二方庫，盡量是 provided 引入，讓二方庫使用

者去依賴具體版本號 ； 無 log 具體實現，只依賴日誌框架。

2 ） 穩定可追溯原則。每個版本的變更應該被記錄，二方函式庫由誰維護，原始碼在哪裡，都需要能

方便查到。除非使用者主動升級版本，否則公共二方庫的行為不應該改變。