二方庫: 公司內部發(fā)布到中央倉庫靡羡，可供公司內部其它應用依賴的庫（jar 包）
【強制】定義 GAV 遵從以下規(guī)則：
GroupID 格式：com.{公司/BU }.業(yè)務線 [.子業(yè)務線]系洛，最多 4 級。 說明： {公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一級略步；子業(yè)務線可選描扯。
正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
2） ArtifactID 格式：產品線名-模塊名。語義不重復不遺漏趟薄，先到中央倉庫去查證一下绽诚。
正例：dubbo-client / fastjson-api / jstorm-tool
3） Version：詳細規(guī)定參考下方
理解：Maven 中的坐標，使用上面三個向量子倉庫中唯一定位一個 Maven 工程。【強制】二方庫版本號命名方式：主版本號.次版本號.修訂號
1） 主版本號：產品方向改變恩够，或者大規(guī)模 API 不兼容卒落，或者架構不兼容升級。
2） 次版本號：保持相對兼容性蜂桶，增加主要功能特性儡毕，影響范圍極小的 API 不兼容修改。
3） 修訂號：保持完全兼容性扑媚，修復 BUG腰湾、新增次要功能特性等。
說明：注意起始版本號必須為：1.0.0钦购，而不是 0.0.1 正式發(fā)布的類庫必須先去中央倉庫進行查證檐盟，使版本號有延續(xù)性，正式版本號不允許覆蓋升級押桃。如當前版本：1.3.3葵萎，那么下一個 合理的版本號：1.3.4 或 1.4.0 或 2.0.0
理解：
首先明確一下版本管理和版本控制以及快照和發(fā)布版本的區(qū)別:
版本管理: 指項目整體版本的演變過程管理,如從1.0-SNAPSHOT到1.0,再到1.1-SNAPSHOT。
版本控制: 版本控制是指借助版本控制工具(SVN,GIT)追蹤代碼的每一個變更唱凯。
快照(SNAPSHOT): 項目的開發(fā)過程中使用的版本,促進團隊內部交流使用羡忘。
發(fā)布版本: 當需要對外提供使用,我們應該保證構件穩(wěn)定唯一,這類穩(wěn)定的版本稱為發(fā)布版。
發(fā)布版需要滿足的條件:
所有自動化測試應當全部通過磕昼。
項目沒有配置任何快照版本的依賴卷雕。
項目沒有配置任何快照版本的插件。
項目所包含的代碼已經全部提交到版本控制系統(tǒng)中票从。
```
3. 【強制】線上應用不要依賴 SNAPSHOT 版本（安全包除外）漫雕。
```
說明：不依賴 SNAPSHOT 版本是保證應用發(fā)布的冪等性。另外峰鄙，也可以加快編譯時的打包構建浸间。
理解：
冪等性: 指的是相同的參數(shù)重復執(zhí)行總能獲得相同的結果。這樣的特性或者函數(shù)不會影響系統(tǒng)狀態(tài),也不用擔心重復執(zhí)行會對系統(tǒng)造成改變吟榴。
- 【強制】二方庫的新增或升級魁蒜，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變吩翻， 必須明確評估和驗證兜看，建議進行 dependency:resolve 前后信息比對，如果仲裁結果完全不一 致细移，那么通過 dependency:tree 命令佣赖，找出差異點翘地，進行<excludes>排除 jar 包亿扁。
理解：Maven是使用傳遞性依賴的。例如某個項目依賴spring-core,而spring-core又依賴commons-logging,那么自然而然的根據(jù)傳遞性依賴這個項目也依賴commons-logging贮预。
?
排除依賴:項目A依賴于B,但是由于一些原因,不想引入傳遞性依賴C,而是顯示地聲明對于項目C特定版本的依賴,我們需要使用exclusions元素聲明排除依賴。如下例子:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.glorze.maven</groupId>
<artifactId>glorzeMaven</artifactId>
<version>1.0.0</version>
<dependencies>
<dependency>
<groupId>com.glorze.maven</groupId>
<artifactId>glorzeMaven2</artifactId>
<version>1.0.0</version>
<exclusions>
<exclusion>
<groupId>com.glorze.maven</groupId>
<artifactId>glorzeMaven3</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.glorze.maven</groupId>
<artifactId>glorzeMaven3</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
</project>
?
dependency:resolve 找出該項目所依賴的項目(jar)列表；dependency:tree 查看整個項目的依賴樹 exclusions 用來排除傳遞性依賴。詳見：
[Maven詳解（五）------ 坐標的概念以及依賴管理](https://www.cnblogs.com/ysocean/p/7451054.html)
- 【強制】二方庫里可以定義枚舉類型谭跨，參數(shù)可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的 POJO 對象声诸。
理解：關于原因以及解釋,這里引用孤盡在知乎的原回答,非常合理酱讶。
?
由于升級原因，導致雙方的枚舉類不盡相同彼乌，在接口解析泻肯，類反序列化時出現(xiàn)異常。Java中出現(xiàn)的任何元素慰照，在Gosling的角度都會有背后的思考和邏輯（盡管并非絕對完美灶挟，但Java的頂層抽象已經是天才級了），比如：接口毒租、抽象類稚铣、注解、和本文提到的枚舉墅垮。枚舉有好處惕医，類型安全，清晰直接算色，還可以使用等號來判斷抬伺，也可以用在switch中。它的劣勢也是明顯的灾梦，就是不要擴展峡钓〖梭希可是為什么在返回值和參數(shù)進行了區(qū)分呢，如果不兼容能岩，那么兩個都有問題寞宫，怎么允許參數(shù)可以有枚舉。當時的考慮捧灰，如果參數(shù)也不能用淆九，那么枚舉幾乎無用武之地了。參數(shù)輸出毛俏，畢竟是本地決定的，你本地有的饲窿，傳送過去煌寇，向前兼容是不會有問題的。但如果是接口返回逾雄，就比較惡心了阀溶，因為解析回來的這個枚舉值，可能本地還沒有鸦泳，這時就會拋出序列化異常银锻。
?
比如：你的本地枚舉類，有一個天氣Enum：SUNNY, RAINY, CLOUDY做鹰，如果根據(jù)天氣計算心情的方法：guess(WeatcherEnum xx)击纬，傳入這三個值都是可以的。返回值：Weatherguess(參數(shù))钾麸，那么對方運算后更振，返回一個SNOWY，本地枚舉里沒有這個值饭尝，傻眼了肯腕。
- [強制] 依賴于一個二方庫時,必須定義一個統(tǒng)一的版本變量,避免版本號不一致。
說明：依賴 springframework-core,-context,-beans钥平，它們都是同一個版本实撒，可以定義一 個變量來保存版本：${spring.version}，定義依賴的時候涉瘾，引用該版本知态。
?
理解：有點像常量，統(tǒng)一睡汹。
- 【強制】禁止在子項目的 pom 依賴中出現(xiàn)相同的 GroupId肴甸，相同的 ArtifactId，但是不同的 Version囚巴。
說明：在本地調試時會使用各子項目指定的版本號原在，但是合并成一個 war友扰，只能有一個版本號 出現(xiàn)在最后的 lib 目錄中∈粒可能出現(xiàn)線下調試是正確的村怪，發(fā)布到線上卻出故障的問題。
?
理解：避免由于版本不同導致的線上與線下不一致浮庐。
- 【推薦】所有 pom 文件中的依賴聲明放在<dependencies>語句塊中甚负，所有版本仲裁放在 <dependencyManagement>語句塊中。
說明：<dependencyManagement>里只是聲明版本审残，并不實現(xiàn)引入梭域，因此子項目需要顯式的聲 明依賴，version 和 scope 都讀取自父 pom搅轿。而<dependencies>所有聲明在主 pom 的 <dependencies>里的依賴都會自動引入病涨，并默認被所有的子項目繼承。
?
理解：dependencyManagement里只是聲明依賴璧坟，并不實現(xiàn)引入既穆，因此子項目需要顯式的聲明需要用的依賴。
?
Maven 使用dependencyManagement 元素來提供了一種管理依賴版本號的方式雀鹃。通常會在一個組織或者項目的最頂層的父POM 中看到dependencyManagement 元素幻工。使用pom.xml 中的dependencyManagement 元素能讓所有在子項目中引用一個依賴而不用顯式的列出版本號。Maven 會沿著父子層次向上走黎茎，直到找到一個擁有dependencyManagement 元素的項目囊颅，然后它就會使用在這個dependencyManagement 元素中指定的版本號。
?
如果有多個子項目都引用同一樣依賴工三，則可以避免在每個使用的子項目里都聲明一個版本號迁酸，這樣當想升級或切換到另一個版本時，只需要在頂層父容器里更新俭正，而不需要一個一個子項目的修改 奸鬓；另外如果某個子項目需要另外的一個版本，只需要聲明version就可掸读。 參見實例：
[dependencies與dependencyManagement的區(qū)別](https://blog.csdn.net/liutengteng130/article/details/46991829)
- 【推薦】二方庫不要有配置項串远，最低限度不要再增加配置項。
理解：為了方便實用,直接一個jar包儿惫。
- 【參考】為避免應用二方庫的依賴沖突問題澡罚，二方庫發(fā)布者應當遵循以下原則：
1）精簡可控原則。移除一切不必要的 API 和依賴肾请，只包含 Service API留搔、必要的領域模型對 象、Utils 類铛铁、常量隔显、枚舉等却妨。如果依賴其它二方庫，盡量是 provided 引入括眠，讓二方庫使用 者去依賴具體版本號彪标；無 log 具體實現(xiàn)，只依賴日志框架掷豺。
2）穩(wěn)定可追溯原則捞烟。每個版本的變化應該被記錄，二方庫由誰維護当船，源碼在哪里题画，都需要能 方便查到。除非用戶主動升級版本生年，否則公共二方庫的行為不應該發(fā)生變化婴程。
```?
理解：
Maven的依賴范圍:
?
compile 編譯依賴范圍。沒有指定的話默認使用使用該依賴范圍抱婉。
test 測試依賴范圍。
provided 已提供依賴范圍桌粉。使用此依賴范圍的Maven依賴,對于編譯和測試classpath有效,但在運行時無效,典型的例子就是servlet-api,運行時tomcat容器已經提供了蒸绩。
runtime 運行時依賴范圍。
system 系統(tǒng)依賴范圍铃肯。慎用!!!
import 導入依賴范圍,支持Maven2.0.9以上版本患亿。只在<dependenciesManagement>元素下才有效果,使用該范圍的依賴通常指向一個pom,作用是將目標pom中的<dependenciesManagement>配置導入并合并到當前pom的<dependenciesManagement>元素中。
