Two-party library specification
1. [Mandatory] Define GAV to comply with the following rules:
1) G GroupID format: com.{Company/BU}.Business Line.[Sub-Business Line], up to 4 levels.
Description: {Company/BU} For example: alibaba/taobao/tmall/aliexpress, etc. BU level one; sub-business lines are optional.
Positive example: com . taobao . jstorm or com.alibaba.dubbo.register
2) A ArtifactID format: product line name-module name. The semantics are not repeated or omitted. First go to the warehouse center to verify.
Example: dubbo - client / fastjson - api / jstorm - tool
3) V Version: Please refer to the details below.
2. [Mandatory] The second-party library version number naming method: major version number. minor version number. revision number
1) major version number Version number: When incompatible API modifications are made, or new features that change the product direction are added.
2) Minor version number Minor version number: regarded as a backward compatible functional addition (new classes, interfaces, etc.).
3) Revision number Revision number: Fix bugs, enhance functions without modifying method signatures, and maintain API compatibility.
Note: The starting version number must be: 1.0.0, not 0.0.1
3. [Mandatory] Do not rely on SNAPSHOT for online applications Version (except for security packages); Officially released class libraries must use the RELEASE version number upgrade method of 1, and the version number is not allowed to be overwritten and upgraded, and must be verified in the central warehouse.
Note: Not relying on the SNAPSHOT version ensures the idempotence of application release. In addition, it can also speed up the packaging and construction during compilation.
#4. [Mandatory] The addition or upgrade of the second-party library will keep the arbitration results of other jar packages except function points unchanged. If there are changes, must be clearly evaluated and verified. It is recommended to compare the information before and after dependency : resolve. If the arbitration results are completely inconsistent , then use the dependency : tree command to find out the differences and proceed < excludes >Exclude jar packages.
5. [Mandatory] The second-party library can define enumeration types, and the parameters can use enumeration types, but the interface return value is not allowed to use enumerationsEnumeration type or POJO object containing enumeration type.
#6. [Mandatory] When relying on a second-party library group, a unified version variable must be defined to avoid version number inconsistency.
Description: Depend on springframework - core, - context, - beans, they are all the same version, you can define a variable to save the version: ${ spring . version }, when defining dependencies, Cite this version.
7. [Mandatory] It is forbidden to have the same GroupId, the same ArtifactId, but different Version in the pom dependencies of sub-projects.
Note: The version number specified by each sub-project will be used during local debugging, but when merged into a war, only one version number can appear in the final lib directory. There have been precedents where offline debugging was correct but problems occurred when released online.
8. [Recommendation] Place the dependency declarations in all pom files in the < dependencies > statement block, and place all version arbitrations in < ; dependencyManagement > in statement block.
Note: < dependencyManagement > only declares the version and does not implement the introduction. Therefore, the sub-project needs to explicitly declare the dependency. Version and scope are both read from the parent pom. And < dependencies > All dependencies declared in < dependencies > of the main pom will be automatically introduced and inherited by all sub-projects by default.
