ここで述べたように、Maven によって提供されるスコーピングの用途を理解するのに苦労しています。
コンパイル時のスコープを常に持つべきではないのはなぜですか? 実際の例は本当にありがたいです。
コンパイル
これらの jar ファイルを準備済みの War ファイルにコピーします。
例: hibernate-core.jar は、準備された War に必要です。
これらの jar は、コンパイル時とテスト時にのみ考慮されます
例:
servlet.jar
デプロイされたサーバーによって提供されるため、準備された War ファイルから提供する必要はありません。
テスト
これらの jar は、テスト クラスを実行するためにのみ必要です。
例: Junit.jar は、Junit テスト クラスを実行する場合にのみ必要です。これらをデプロイする必要はありません。
スコープ付き依存関係は、compile
コンパイル中にのみ使用されます。
範囲指定されたtest
もの -- テスト中のみ。junit または easymock を使用したテストがあるとします。最終的なアーティファクトをそれらに依存させたくないのは明らかですが、テストの実行中にこれらのライブラリに依存できるようにしたいと考えています。
マークされた依存関係はprovided
、生成されたアーティファクトを実行しているときにクラスパスにあると予想されます。たとえば、webapp があり、サーブレット ライブラリに依存しているとします。明らかに、WAR ファイル内にパッケージ化しないでください。webapp コンテナーに既に含まれているため、競合が発生する可能性があります。
依存関係のスコープが異なる理由の 1 つは、ビルドのさまざまな部分がさまざまな依存関係に依存する可能性があるためです。たとえば、コードをコンパイルするだけで、テストを実行しない場合、Maven にテストの依存関係をダウンロードしても意味がありません (もちろん、ローカル リポジトリにまだ存在しない場合)。もう 1 つの理由は、一部の依存関係はビルドおよびテスト段階でのみ使用されるため、すべての依存関係を最終的なアーティファクト (アセンブリまたは WAR ファイルであるかどうか) に配置する必要があるわけではないことです。
スコープはここで非常によく説明されています: https://maven.apache.org/pom.html#Dependencies
参考までに、以下の段落をコピーしました。
scope: この要素は、目前のタスク (コンパイルとランタイム、テストなど) のクラスパスと、依存関係の推移性を制限する方法を参照します。利用可能なスコープは 5 つあります。
compile - これはデフォルトのスコープで、何も指定されていない場合に使用されます。コンパイルの依存関係は、すべてのクラスパスで利用できます。さらに、それらの依存関係は依存プロジェクトに伝播されます。
provided - これは compile によく似ていますが、JDK またはコンテナーが実行時にそれを提供することを期待していることを示します。コンパイルおよびテスト クラスパスでのみ使用でき、推移的ではありません。
ランタイム- このスコープは、依存関係がコンパイルには必要ないが、実行には必要であることを示します。これはランタイムおよびテスト クラスパスにありますが、コンパイル クラスパスにはありません。
test - このスコープは、依存関係がアプリケーションの通常の使用には必要なく、テストのコンパイルおよび実行フェーズでのみ使用できることを示します。
system - このスコープは、それを含む JAR を明示的に提供する必要があることを除いて、provided と似ています。アーティファクトは常に利用可能で、リポジトリで検索されません。
すべての依存関係をデフォルトのコンパイル スコープにしたくない理由がいくつかあります。