1. 【強制】定義GAV遵從以下規則： 1） GroupID格式：com.{公司/BU }.業務線.\[子業務線\]，最多4級。 說明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress等BU一級；子業務線可選。 正例：com.taobao.jstorm 或 com.alibaba.dubbo.register 2） ArtifactID格式：產品線名-模塊名。語義不重復不遺漏，先到中央倉庫去查證一下。 正例：dubbo-client / fastjson-api / jstorm-tool 3） Version：詳細規定參考下方。 1. 【強制】二方庫版本號命名方式：主版本號.次版本號.修訂號 1） 主版本號：產品方向改變，或者大規模API不兼容，或者架構不兼容升級。 2） 次版本號：保持相對兼容性，增加主要功能特性，影響范圍極小的API不兼容修改。 3） 修訂號：保持完全兼容性，修復BUG、新增次要功能特性等。 說明：注意起始版本號必須為：1.0.0，而不是0.0.1 正式發布的類庫必須先去中央倉庫進行查證，使版本號有延續性，正式版本號不允許覆蓋升級。如當前版本：1.3.3，那么下一個合理的版本號：1.3.4 或 1.4.0 或 2.0.0 1. 【強制】線上應用不要依賴SNAPSHOT版本（安全包除外）。 說明：不依賴SNAPSHOT版本是保證應用發布的冪等性。另外，也可以加快編譯時的打包構建。 1. 【強制】二方庫的新增或升級，保持除功能點之外的其它jar包仲裁結果不變。如果有改變， 必須明確評估和驗證，建議進行dependency:resolve前后信息比對，如果仲裁結果完全不一致，那么通過dependency:tree命令，找出差異點，進行<excludes>排除jar包。 1. 【強制】二方庫里可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的POJO對象。 2. 【強制】依賴于一個二方庫群時，必須定義一個統一的版本變量，避免版本號不一致。 說明：依賴springframework-core,-context,-beans，它們都是同一個版本，可以定義一個變量來保存版本：${spring.version}，定義依賴的時候，引用該版本。 1. 【強制】禁止在子項目的pom依賴中出現相同的GroupId，相同的ArtifactId，但是不同的 Version。 說明：在本地調試時會使用各子項目指定的版本號，但是合并成一個war，只能有一個版本號出現在最后的lib目錄中。可能出現線下調試是正確的，發布到線上卻出故障的問題。 1. 【推薦】所有pom文件中的依賴聲明放在<dependencies>語句塊中，所有版本仲裁放在 <dependencyManagement>語句塊中。 說明：<dependencyManagement>里只是聲明版本，并不實現引入，因此子項目需要顯式的聲 明依賴，version和scope都讀取自父pom。而<dependencies>所有聲明在主pom的 <dependencies>里的依賴都會自動引入，并默認被所有的子項目繼承。 1. 【推薦】二方庫不要有配置項，最低限度不要再增加配置項。 2. 【參考】為避免應用二方庫的依賴沖突問題，二方庫發布者應當遵循以下原則： 1） 精簡可控原則。移除一切不必要的API和依賴，只包含 Service API、必要的領域模型對象、Utils類、常量、枚舉等。如果依賴其它二方庫，盡量是provided引入，讓二方庫使用者去依賴具體版本號；無log具體實現，只依賴日志框架。 2） 穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪里，都需要能方便查到。除非用戶主動升級版本，否則公共二方庫的行為不應該發生變化。