2

関連するすべてのサブモジュールの親 POM としても機能するマルチモジュール POM があります。それを呼び出しますMultiModulePOM。Module1に番号が付けられた約 70 のモジュールがありますModule70。

現在: これらのモジュールの最初の 30 個は、コンパイル時にのみ一連の JAR ファイルを必要とします。それは -scope=providedです。一連の JAR ファイルについて話しているので、これらの 30 個のモジュールを同期しておくのは非常に面倒です。一般的に、私は定義をあちこちにコピーすることはあまり好きではありません。

そこで、依存関係のグループ化の落とし穴に陥りました。良いアイデアのように思えましたが、provided依存関係では機能しません。つまり、依存する JAR を というモジュールにグループ化し、依存させるExtDependenciesと、によって参照される JARは、スコープが であるため、に推移的に追加されません。Module1ExtDependenciesExtDependenciesModule1provided

（最後のパラグラフが真実でない場合は、私を本当に窮地から解放することができるので、私に知らせてください）

私が見ることができた他の唯一のオプションは、 (たとえば) という名前の親 POM を作成することでしたIntermediaryPOM。依存する JAR ファイルのセットをIntermediaryPOM拡張して登録します。モジュール-次に拡張します。MultiModulePOMscope=providedModule1Module30IntermediaryPOM

それはトリックを行うように見えましたが、3つの問題があります:

  1. 本当に必要かどうかわからないPOMの別のレイヤーが追加されます。
  2. その後、配布時に、中間の POM もインストール/展開する必要があることに気付きました。
  3. 一般的なケースを考えてみましょう。中間 POM には、他の JAR セット (モジュール 31 ～ 50 用) に使用される他の兄弟が含まれる場合があります。したがって、このソリューションはうまくスケーリングできないようです。

だから私の質問は - あなたの経験によると、これにアプローチする最良の方法は何ですか? そのようなユースケースの既知のベストプラクティスはありますか?

4

1 に答える 1

1

ここには簡単な解決策はありません。

ExtDependenciesで共通の依存関係を宣言すると、providedそれらは に依存する他のモジュールのクラスパスに追加されないというのは正しいことですExtDependencies。それがどのように機能するかprovidedです。

ただし、これらの共通の依存関係をスコープなしで (たとえば、デフォルトのスコープで) 宣言し、依存関係compileを追加することもできます。この場合、すべての依存関係がクラスパスに追加されます。神、それは多くの「依存関係」です:)providedExtDependenciesExtDependencies

また、他の可能なオプションについても言及しました-別のレベルの抽象化を導入します（ご存知かもしれませんが、これはほとんどすべての問題を解決する方法です）。しかし、そのようなマルチレベルの階層は洗練されておらず、維持するのがより困難です (私はプロジェクトにそれを持っているので、そこに行ってきました)。

一般的に、私はそのような規模でこの問題に遭遇したことはありませんが、それを解決する場合は、スコープの提案を考慮して最初のオプションを使用します.

于 2013-02-07T18:08:31.870 に答える