1. [Mandatory] Rules of defining GAV:
  1) GroupID: com.{company/BU}.{business line}.{sub business line}, at most 4 levels

Note: {company/BU} for example: such business unit level as Alibaba, Taobao, Tmall, Aliexpress and so on; sub-business line is optional.

Positive example: com.taobao.tddl   com.alibaba.sourcing.multilang

  2) ArtifactID: Product name - module name.

Positive example: tc-client / uic-api / tair-tool

  3) Version: Please refer to below

2. [Mandatory] Library naming convention: prime version number.secondary version number.revision number
  1) prime version number: Need to change when there are incompatible API modification, or new features that can change the product direction.
  2) secondary version number: Changed for backward compatible modification.
  3) revision number: Changed for fixing bugs or adding features that do not modify the method signature and maintain API compatibility.

Note: The initial version must be 1.0.0, rather than 0.0.1.

3. [Mandatory] Online applications should not depend on SNAPSHOT versions (except for security packages); Official releases must be verified from central repository, to make sure that the RELEASE version number has continuity. Version numbers are not allowed to be overridden.

Note: Avoid using SNAPSHOT is to ensure the idempotent of application release. In addition, it can speed up the code compilation when packaging. If the current version is 1.3.3, then the number for the next version can be 1.3.4, 1.4.0 or 2.0.0.

4. [Mandatory] When adding or upgrading libraries, remain the versions of dependent libraries unchanged if not necessary. If there is a change, it must be correctly assessed and checked. It is recommended to use command dependency:resolve to compare the information before and after. If the result is identical, find out the differences with the command dependency:tree and use \ to eliminate unnecessary libraries.

5. [Mandatory] Enumeration types can be defined or used for parameter types in libraries, but cannot be used for interface return types (POJO that contains enumeration types is also not allowed).

6. [Mandatory] When a group of libraries are used, a uniform version variable need to be defined to avoid the inconsistency of version numbers.

Note: When using springframework-core, springframework-context, springframework-beans with the same version, a uniform version variable \${spring.version} is recommended to be used.

7. [Mandatory] For the same GroupId and ArtifactId, Version must be the same in sub-projects.

Note: During local debugging, version number specified in sub-project is used. But when merged into a war, only one version number is applied in the lib directory. Therefore, such case might occur that offline debugging is correct, but failure occurs after online launch.

8. [Recommended] The declaration of dependencies in all POM files should be placed in \ block. Versions of dependencies should be specified in \ block.

Note: In \ versions of dependencies are specified, but dependencies are not imported. Therefore, in sub-projects dependencies need to be declared explicitly, version and scope of which are read from the parent POM. All declarations in \ in the main POM will be automatically imported and inherited by all subprojects by default.

9. [Recommended] It is recommended that libraries do not include configuration, at least do not increase the configuration items.

10. [For Reference] In order to avoid the dependency conflict of libraries, the publishers should follow the principles below:
  1) Simple and controllable: Remove all unnecessary API and dependencies, only contain Service API, necessary domain model objects, Utils classes, constants, enumerations, etc. If other libraries must be included, better to make the scope as provided and let users to depend on the specific version number. Do not depend on specific log implementation, only depend on the log framework instead.
  2) Stable and traceable: Change log of each version should be recorded. Make it easy to check the library owner and where the source code is. Libraries packaged in the application should not be changed unless the user updates the version proactively.