二方库: 公司内部发布到中央仓库，可供公司内部其它应用依赖的库（jar 包）
【强制】定义 GAV 遵从以下规则：
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：详细规定参考下方
理解：Maven 中的坐标，使用上面三个向量子仓库中唯一定位一个 Maven 工程。【强制】二方库版本号命名方式：主版本号.次版本号.修订号
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.0-SNAPSHOT到1.0,再到1.1-SNAPSHOT。
版本控制: 版本控制是指借助版本控制工具(SVN,GIT)追踪代码的每一个变更。
快照(SNAPSHOT): 项目的开发过程中使用的版本,促进团队内部交流使用。
发布版本: 当需要对外提供使用,我们应该保证构件稳定唯一,这类稳定的版本称为发布版。
发布版需要满足的条件:
所有自动化测试应当全部通过。
项目没有配置任何快照版本的依赖。
项目没有配置任何快照版本的插件。
项目所包含的代码已经全部提交到版本控制系统中。
```
3. 【强制】线上应用不要依赖 SNAPSHOT 版本（安全包除外）。
```
说明：不依赖 SNAPSHOT 版本是保证应用发布的幂等性。另外，也可以加快编译时的打包构建。
理解：
幂等性: 指的是相同的参数重复执行总能获得相同的结果。这样的特性或者函数不会影响系统状态,也不用担心重复执行会对系统造成改变。
- 【强制】二方库的新增或升级，保持除功能点之外的其它 jar 包仲裁结果不变。如果有改变， 必须明确评估和验证，建议进行 dependency:resolve 前后信息比对，如果仲裁结果完全不一 致，那么通过 dependency:tree 命令，找出差异点，进行<excludes>排除 jar 包。
理解：Maven是使用传递性依赖的。例如某个项目依赖spring-core,而spring-core又依赖commons-logging,那么自然而然的根据传递性依赖这个项目也依赖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)
- 【强制】二方库里可以定义枚举类型，参数可以使用枚举类型，但是接口返回值不允许使用枚举类型或者包含枚举类型的 POJO 对象。
理解：关于原因以及解释,这里引用孤尽在知乎的原回答,非常合理。
由于升级原因，导致双方的枚举类不尽相同，在接口解析，类反序列化时出现异常。Java中出现的任何元素，在Gosling的角度都会有背后的思考和逻辑（尽管并非绝对完美，但Java的顶层抽象已经是天才级了），比如：接口、抽象类、注解、和本文提到的枚举。枚举有好处，类型安全，清晰直接，还可以使用等号来判断，也可以用在switch中。它的劣势也是明显的，就是不要扩展。可是为什么在返回值和参数进行了区分呢，如果不兼容，那么两个都有问题，怎么允许参数可以有枚举。当时的考虑，如果参数也不能用，那么枚举几乎无用武之地了。参数输出，毕竟是本地决定的，你本地有的，传送过去，向前兼容是不会有问题的。但如果是接口返回，就比较恶心了，因为解析回来的这个枚举值，可能本地还没有，这时就会抛出序列化异常。
比如：你的本地枚举类，有一个天气Enum：SUNNY, RAINY, CLOUDY，如果根据天气计算心情的方法：guess(WeatcherEnum xx)，传入这三个值都是可以的。返回值：Weatherguess(参数)，那么对方运算后，返回一个SNOWY，本地枚举里没有这个值，傻眼了。
- [强制] 依赖于一个二方库时,必须定义一个统一的版本变量,避免版本号不一致。
说明：依赖 springframework-core,-context,-beans，它们都是同一个版本，可以定义一 个变量来保存版本：${spring.version}，定义依赖的时候，引用该版本。
理解：有点像常量，统一。
- 【强制】禁止在子项目的 pom 依赖中出现相同的 GroupId，相同的 ArtifactId，但是不同的 Version。
说明：在本地调试时会使用各子项目指定的版本号，但是合并成一个 war，只能有一个版本号 出现在最后的 lib 目录中。可能出现线下调试是正确的，发布到线上却出故障的问题。
理解：避免由于版本不同导致的线上与线下不一致。
- 【推荐】所有 pom 文件中的依赖声明放在<dependencies>语句块中，所有版本仲裁放在 <dependencyManagement>语句块中。
说明：<dependencyManagement>里只是声明版本，并不实现引入，因此子项目需要显式的声 明依赖，version 和 scope 都读取自父 pom。而<dependencies>所有声明在主 pom 的 <dependencies>里的依赖都会自动引入，并默认被所有的子项目继承。
理解：dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显式的声明需要用的依赖。
Maven 使用dependencyManagement 元素来提供了一种管理依赖版本号的方式。通常会在一个组织或者项目的最顶层的父POM 中看到dependencyManagement 元素。使用pom.xml 中的dependencyManagement 元素能让所有在子项目中引用一个依赖而不用显式的列出版本号。Maven 会沿着父子层次向上走，直到找到一个拥有dependencyManagement 元素的项目，然后它就会使用在这个dependencyManagement 元素中指定的版本号。
如果有多个子项目都引用同一样依赖，则可以避免在每个使用的子项目里都声明一个版本号，这样当想升级或切换到另一个版本时，只需要在顶层父容器里更新，而不需要一个一个子项目的修改 ；另外如果某个子项目需要另外的一个版本，只需要声明version就可。 参见实例：
[dependencies与dependencyManagement的区别](https://blog.csdn.net/liutengteng130/article/details/46991829)
- 【推荐】二方库不要有配置项，最低限度不要再增加配置项。
理解：为了方便实用,直接一个jar包。
- 【参考】为避免应用二方库的依赖冲突问题，二方库发布者应当遵循以下原则：
1）精简可控原则。移除一切不必要的 API 和依赖，只包含 Service API、必要的领域模型对 象、Utils 类、常量、枚举等。如果依赖其它二方库，尽量是 provided 引入，让二方库使用 者去依赖具体版本号；无 log 具体实现，只依赖日志框架。
2）稳定可追溯原则。每个版本的变化应该被记录，二方库由谁维护，源码在哪里，都需要能 方便查到。除非用户主动升级版本，否则公共二方库的行为不应该发生变化。
```
理解：
Maven的依赖范围:
compile 编译依赖范围。没有指定的话默认使用使用该依赖范围。
test 测试依赖范围。
provided 已提供依赖范围。使用此依赖范围的Maven依赖,对于编译和测试classpath有效,但在运行时无效,典型的例子就是servlet-api,运行时tomcat容器已经提供了。
runtime 运行时依赖范围。
system 系统依赖范围。慎用!!!
import 导入依赖范围,支持Maven2.0.9以上版本。只在<dependenciesManagement>元素下才有效果,使用该范围的依赖通常指向一个pom,作用是将目标pom中的<dependenciesManagement>配置导入并合并到当前pom的<dependenciesManagement>元素中。
