Spécification de bibliothèque bipartite


1. [Obligatoire] Définissez GAV pour respecter les règles suivantes :

1) Format G GroupID : com.{Société/BU}.Business Line.[Sous-Business Line], jusqu'à 4 niveaux.

Description : {Entreprise/BU} Par exemple : alibaba / taobao / tmall / aliexpress, etc. Les sous-lignes d'activité de la BU sont facultatives.

Exemple positif : com . taobao . jstorm ou com.alibaba.dubbo.register

2) Un format ArtifactID : nom de la ligne de produit-nom du module. La sémantique n'est ni répétée ni omise. Rendez-vous d'abord au centre d'entrepôt pour vérifier.

Exemple : dubbo - client / fastjson - api / jstorm - outil

3) Version V : Veuillez vous référer aux détails ci-dessous.


2. [Obligatoire] Méthode de dénomination du numéro de version de la bibliothèque tierce : numéro de version majeure, numéro de révision mineure

1) Numéro de version majeure Numéro de version majeure : lorsque des modifications ou des ajouts d'API incompatibles sont effectués. fonctionnalités qui changent la direction du produit.

2) Numéro de version mineure Numéro de version mineure : considéré comme un ajout fonctionnel rétrocompatible (nouvelles classes, interfaces, etc.).

3) Numéro de révision Numéro de révision : corrigez les bugs, améliorez les fonctions sans modifier les signatures de méthode et maintenez la compatibilité API.

Remarque : le numéro de version de départ doit être : 1.0.0, et non 0.0.1


3. [Obligatoire] Les applications en ligne ne s'appuient pas sur la version SNAPSHOT (sauf pour les packages de sécurité officiellement publiés) ; être utilisé RELEASELe numéro de version est mis à niveau de +1 et le numéro de version ne peut pas être écrasé et mis à niveau. Vous devez vous rendre à l'entrepôt central pour vérification.

Remarque : ne pas s'appuyer sur la version SNAPSHOT garantit l'idempotence de la version de l'application. De plus, cela peut également accélérer le packaging et la construction lors de la compilation.


4. [Obligatoire] L'ajout ou la mise à niveau de la bibliothèque tierce conservera les résultats d'arbitrage des autres packages jar inchangés, à l'exception des points de fonction. S'il y a un changement, il doit être clairement évalué et vérifié. Il est recommandé de comparer les informations avant et après dependency : solve. Si les résultats de l'arbitrage sont complètement incohérents, utilisez la commande dependency : tree pour connaître les différences et effectuer. < exclut >

5. [Obligatoire] Les bibliothèques tierces peuvent définir des types d'énumération et les paramètres peuvent utiliser des types d'énumération, mais les valeurs de retour d'interface ne sont pas autorisées à utiliser des types d'énumération ou des objets POJO contenant des types d'énumération.

6. [Obligatoire] Lorsque vous comptez sur un groupe de bibliothèques tiers, une variable de version unifiée doit être définie pour éviter l'incohérence du numéro de version.


Remarque : Dépend de springframework - core, - context, - beans. Ils sont tous de la même version. Vous pouvez définir une variable pour enregistrer la version : ${ spring version }.

7. [Obligatoire] Il est interdit d'avoir le même GroupId et le même ArtifactId mais des

Version différentes dans les dépendances pom des sous-projets.


Remarque : lors du débogage local, le numéro de version spécifié par chaque sous-projet sera utilisé, mais lorsqu'il est fusionné dans une guerre, un seul numéro de version peut apparaître dans le répertoire final lib. Il y a eu des précédents où le débogage hors ligne était correct mais des problèmes survenaient lors de la mise en ligne.


8. [Recommandé] Placez les déclarations de dépendance dans tous les fichiers pom dans le bloc d'instructions < dependencies > et placez tous les arbitrages de version dans le bloc d'instructions <

Remarque : Le < dependencyManagement > déclare uniquement la version et n'implémente pas l'introduction. Par conséquent, le sous-projet doit déclarer explicitement la dépendance. La version et la portée sont lues à partir du pom parent. Et < dépendances > Toutes les dépendances déclarées dans < du pom principal seront automatiquement introduites et héritées par tous les sous-projets.


9. [Recommandation] La bibliothèque tierce devrait essayer de ne pas avoir d'éléments de configuration, et au moins ne pas ajouter d'éléments de configuration supplémentaires.


10. [Référence] Afin d'éviter les conflits de dépendances lors de l'application de bibliothèques tierces, les éditeurs de bibliothèques tierces doivent suivre les principes suivants :

1) Le principe de simplicité et de contrôlabilité. Supprimez toutes les API et dépendances inutiles, y compris uniquement l'API de service, les objets de modèle de domaine nécessaires, les classes Utils, les constantes, les énumérations, etc. Si vous comptez sur d'autres bibliothèques tierces, essayez de les présenter avec les informations fournies, afin que les utilisateurs des bibliothèques tierces puissent s'appuyer sur les numéros de version spécifiques. Il n'y a pas d'implémentation spécifique du journal et vous comptez uniquement sur le framework de journalisation ; .

2) Principe de traçabilité stable. Les modifications apportées à chaque version doivent être enregistrées, qui gère la bibliothèque tierce et où se trouve le code source, tous doivent être facilement accessibles. Le comportement des bibliothèques publiques tierces ne devrait pas changer à moins que l'utilisateur ne mette activement à niveau la version.