Maven Javaインターフェイスと実装のマルチモジュールの問題

Question

私は2つのモジュール、すなわちapiとserviceを持つ再利用プロジェクトを持っているとしましょう。再利用APIモジュールは、他のアプリケーションプロジェクトで使用できるインタフェース、タイプ、注釈を定義します。再利用サービスモジュールには実際の実装が含まれています。再利用プロジェクトは、次のようになります。

pom.xml: id=reuse, group=com.test.project, version=1.0.0 
|__api-module 
     |__pom.xml: parent={id=reuse, group=com.test.project, version=1.0.0}, id=reuse-api 
|__service-module 
     |__pom.xml: parent={id=reuse, group=com.test.project, version=1.0.0}, id=reuse-srv 

また、再利用モジュールには難点があります。

pom.xml: id=application, group=com.test.project, version=2.0.0 
     dependency={scope=compile, id=reuse-api, group=com.test.project, version=1.0.0} 
     dependency={scope=runtime, id=reuse-srv, group=com.test.project, version=1.0.0} 

今我々は再利用モジュールのimplimentation、全体の再使用モジュール（APIおよびサービス）であるとしているの変更を意味し、再利用サービスモジュールで何かを変更した場合の事は、ありますapiとサービスモジュールのバージョンが親モジュールから継承されるため、新しいバージョンがリリースされます。新しいポンポン構造は次のようになります。その後

pom.xml: id=reuse, group=com.test.project, version=1.0.1 
|__api-module 
     |__pom.xml: parent={id=reuse, group=com.test.project, version=1.0.1}, id=reuse-api 
|__service-module 
     |__pom.xml: parent={id=reuse, group=com.test.project, version=1.0.1}, id=reuse-srv 

、アプリケーションは再利用の新しいバージョンで依存関係を変更することがあります。

pom.xml: id=application, group=com.test.project, version=2.0.1 
     dependency={scope=compile, id=reuse-api, group=com.test.project, version=1.0.1} 
     dependency={scope=runtime, id=reuse-srv, group=com.test.project, version=1.0.1} 

の変更という方法はあります再利用サービスモジュールはアプリケーションにも変更をもたらさないでしょうか？アプリケーションは、実際に再利用の実装の変更によって影響を受ける必要はありませんか？

いくつかのコメント/提案がありますか？ありがとうございました。

Answer 1

モジュールは、複数のアプリケーション間で共有されているがあり

service-api-1.0.0 
service-impl-1.0.0 

（例えば、いくつかのrepository managerがあなたの会社でホストされている）あなたは2つのモジュールは、いくつかの成果物のリポジトリに格納されていることを前提としています：

app-1 
    compile: service-api-1.0.0 
    runtime: service-impl-1.0.0 
app-2 
    compile: service-api-1.0.0 
    runtime: service-impl-1.0.0 

アプリケーションはビルド構成（additional maven repository）でリポジトリを定義し、バージョン番号で参照する必要があります。

API /実装の変更を完了するたびに、より高いバージョンのライブラリをリリースする必要があります。

Libraryバージョン通常、そこには新しい機能がありませんが、単に既存の機能に修正されたときのバージョンは、各リリースを更新しなければならない3つのコンポーネント[major].[minor].[bugfix]

• Bugfixの外に構成されています。
• Minor以前のリリースと下位互換性のある新機能がある場合、バージョンが更新されます。
• Major互換性のない変更を導入すると、バージョンが変更されます。

など。 service-impl-1.0.0にいくつかの実装上の欠陥を修正する場合は、service-impl-1.0.1をリリースしています。これはまだservice-api-1.0.0とコンパイルされているかもしれません。

この新しいバージョンは、リポジトリにインストールされますあなたはそれがまだコンパイルされるアプリケーションの構成を更新し、リポジトリ内の古いバージョンはまだ利用できに対してビルドない限り、その内容は

service-api-1.0.0 
service-impl-1.0.0 
service-impl-1.0.1 

になります。だから、今持っていることができます限り、彼らはあなたのライブラリーの歴史バージョンへのアクセスを持っているように、各アプリケーションを変更する必要はありません

app-1 
    compile: service-api-1.0.0 
    runtime: service-impl-1.0.0 
app-2 
    compile: service-api-1.0.0 
    runtime: service-impl-1.0.1 

。依存関係のバージョンは、新しい機能を追加する場合にのみ変更します（これは、他の共有共有ライブラリについても同様です）。

Answer 2

あなたはあなたのライブラリーのコードを変更した場合、アプリケーションは3つの選択肢があります：

1. 新しいバージョンを使用して、再度コンパイルを。
2. 古いバージョンをそのまま使用し、変更を無視します。
3. 再度コンパイルしないでください。実行時に新しいライブラリを使用してください。

3番目のオプションは、すべてのインターフェイスとすべての動作を変更する必要がないため、少し危険です。そうしないと、実行時の例外が発生する可能性があります。しかし、それはかなり一般的です。

実際にライブラリの実装をアプリケーションから切り離したい場合は、別の種類の依存関係が必要です。 RESTサービスこの効果は、（3）と似ていますが、RESTサービスの実装を変更しますが、動作とインタフェースが変更されていないことを保証するためです。