外部APIをバージョン管理するためのJavaパッケージの名前付け

Question

外部のバージョン管理されたAPIを使用するクラスを含むJavaパッケージに名前を付ける方法はありますか？

サービスのメジャーマイナーセマンティックバージョニングスキームがあり、そのAPIの特定のバージョンと互換性があり、バインドされたコンシューマーを実装する必要があるとします。パッケージ（およびクラス）に名前を付けるベストプラクティスは何ですか？

現時点では、${service}_${M}_${N}（M =メジャーバージョン、N =マイナーバージョン）というスキームを使用しています。例：com.example.theService_1_0.。 しかし、sonarqubeはそれが慣例と一致しないと訴えています。 もちろん、このルールを無効にすることはできますが、ベストプラクティスがあるのだろうかと思います。

WebService、REST、CORBAのコンシューマ実装が発生したため、REST固有のアプローチだけでなく、一般的なアプローチも探しています。そして、私は確信していませんが、artifact-versioning（mavenのように）はここでうまくいきます。なぜなら、それは実装ではなくAPIであるからです。

api versioningについて質問がありますが、それは消費者ではなくプロデューサーに関するものです。

Answer 1

はい、Javaパッケージ名には、依存関係のバージョンを示すための強力であいまいな規則があります。はではありません。

新しいバージョンの外部APIを使用するようにアプリケーションを変更した場合は、新しいバージョンのアプリケーションを作成します。探しているバージョン番号はアプリケーションのバージョン番号です。多くのJavaプロジェクトでは、依存関係のバージョンはMaven設定ファイルによって管理されます。

いずれの場合でも、クラスが特定のAPIバージョンを使用する場合、クラスとパッケージ名にはこの情報を公開するビジネスはなく、カプセル化に違反します。これらの名前は異なる目的を持っています。

HTTP/REST APIまたはJava APIを使用する場合でも同じです。結局のところ、クラス名をTheServiceWithLog4J_12_1_5とするとは思いません。少なくとも、私は望んでいない。

この外部APIの複数のバージョンを同時にサポートする必要があるかどうかについては言及していません。あなたがしたとしても、私はまだパッケージ名にAPIのバージョン番号を公開することはお勧めしません。代わりに、を示すパッケージ名を使用してください。には2つのバージョンと重要な違いがあります。