ツーパーティ ライブラリの仕様
1. [必須] 次のルールに準拠するように GAV を定義します:
1) G GroupID 形式: com.{会社/BU}.Business Line.[Sub-Business Line]、最大 4レベル。
説明: {会社/BU} 例: alibaba/taobao/tmall/aliexpress など BU レベル 1。サブビジネス ラインはオプションです。
良い例: com . taabao . jstorm または com.alibaba.dubbo.register
2) ArtifactID 形式: 製品ライン名 - モジュール名。セマンティクスが繰り返されたり省略されたりすることはありません。まず倉庫センターに行って確認してください。
例: dubbo - client / fastjson - api / jstorm - tools
3) V バージョン: 以下の詳細を参照してください。
2. [必須] セカンドパーティ ライブラリのバージョン番号の命名方法: メジャー バージョン番号. マイナー バージョン番号. リビジョン番号
1) メジャー バージョン番号 バージョン番号: 互換性のない API の変更が行われた場合、または製品の方向性を変える新機能が追加された場合。
2) マイナー バージョン番号 マイナー バージョン番号: 下位互換性のある機能追加 (新しいクラス、インターフェイスなど) とみなされます。
3) リビジョン番号 リビジョン番号: バグを修正し、メソッド シグネチャを変更せずに機能を拡張し、API の互換性を維持します。
注: 開始バージョン番号は 0.0.1 ではなく 1.0.0 である必要があります: 0.0.1
3 [必須] オンラインでは SNAPSHOT に依存しないでください。アプリケーションのバージョン (セキュリティ パッケージを除く); 正式にリリースされたクラス ライブラリは、RELEASE バージョン番号アップグレード メソッド 1 を使用する必要があり、バージョン番号の上書きやアップグレードは許可されておらず、中央ウェアハウスで検証する必要があります。
注: SNAPSHOT バージョンに依存しないことで、アプリケーションのリリースの冪等性が保証されます。さらに、コンパイル時のパッケージ化と構築も高速化できます。#4. [必須] セカンドパーティ ライブラリを追加またはアップグレードすると、ファンクション ポイントを除く他の jar パッケージの調停結果は変更されません。変更がある場合は、 を明確に評価および検証する必要があります。dependency :solve の前後の情報を比較することをお勧めします。調停結果が完全に矛盾する 場合は、dependency :tree コマンドを使用してください。違いを確認し、< 除外 >jar パッケージの除外に進みます。
5. [必須] セカンドパーティのライブラリは列挙型を定義でき、パラメータは列挙型を使用できますが、インターフェイスの戻り値は列挙型を使用できません。 use enumerations列挙型、または列挙型を含む POJO オブジェクト。
説明: springframework - core、-context、-beans に依存します。これらはすべて同じバージョンです。依存関係を定義するときに、バージョンを保存する 変数 ${ spring . version } を定義できます。 , このバージョンを引用します。
7. [必須] サブプロジェクトの pom 依存関係で、同じ GroupId、同じ ArtifactId、しかし異なる Version を持つことは禁止されています。 。
###注: 各サブプロジェクトで指定されたバージョン番号は、ローカル デバッグ中に使用されますが、war にマージされる場合、最終的な lib ディレクトリに表示できるバージョン番号 は 1 つだけです。オフラインのデバッグは正しくても、オンラインでリリースすると問題が発生したという前例があります。
8. [推奨事項] すべての pom ファイルの依存関係宣言を < dependency > ステートメント ブロックに配置し、すべてのバージョン調停を に配置します。 < ; dependencyManagement > ステートメント ブロック内。
注: < dependencyManagement > はバージョンを宣言するだけであり、導入部分は実装しません。したがって、サブプロジェクトは依存関係を明示的に宣言する必要があります。バージョンとスコープは両方とも親 pom から読み取られます。 。そして < 依存関係 > メイン pom の < 依存関係 > で宣言されたすべての依存関係は、デフォルトですべてのサブプロジェクトに自動的に導入され、継承されます。
##10. [参考] セカンドパーティ ライブラリを適用する際に依存関係の競合を避けるために、セカンドパーティ ライブラリの発行者は次の原則に従う必要があります。 #1) 単純化 制御性の原理。サービス API、必要なドメイン モデル オブジェクト
#、Utils クラス、定数、列挙などを含む、不要な API と依存関係をすべて削除します。他のセカンド パーティ ライブラリに依存する場合は、提供されているとおりにそれらを導入して、セカンド パーティ ライブラリのユーザーが特定のバージョン番号に依存できるようにしてください。ログの特定の実装はなく、ログ フレームワークのみに依存します。
2) 安定したトレーサビリティ原則。各バージョンの変更を記録する必要があり、誰がセカンド パーティ ライブラリを保守しているか、ソース コードがどこにあるか、すべてに簡単にアクセスできる必要があります。ユーザーが積極的にバージョンをアップグレードしない限り、パブリックのセカンドパーティ ライブラリの動作は変更されるべきではありません。
