5

これは一般的な問題のように聞こえるので、使用するビルド/依存関係管理ツール (私の場合は Gradle) に関係なく、これらの状況に対処するための一般的な推奨方法があるかどうか疑問に思っています。いくつかの依存関係が手動で処理され、コマンドを使用して Java で単純にビルドされる小さなプロジェクトであっても、ビルド ツールに関係なくこの問題が発生することは想像できますjar。

私の Java プロジェクトは Velocity 1.7 を使用しているため、クラスパスに Velocity 1.7 JAR があります。

ただし、このプロジェクトは Velocity 1.4 に依存する ReportNG も使用します(マニフェストにもエントリClass-Path: velocity-dep-1.4.jarがあり、ダウンロードされた zip には含まれてvelocity-dep-1.4.jarおり、ホームページvelocity-dep-1.4.jarにはクラスパスにある必要があることが明示的に記載されています)。

クラスパスに両方の Velocity バージョンの JAR が含まれないようにする方法を考えています。

ReportNG で Velocity 1.4 の代わりに 1.7 を使用するようにしようとしていますが、必ずしもうまくいくとは限りません。これらの状況に対処するクリーンな方法がある場合は、それを避けたいと思います。

4

1 に答える 1

2

両方の JAR をクラスパスに追加できますが、デフォルトでは、Java は特定のクラスを含む最初の JAR を使用します。これは、クラスパスの作成方法によっては、システムに望ましくない影響を与える可能性があります。

この状況を回避するために、Gradle (それ以前の Maven と同様) はビルド時に依存関係の競合を解決します。

Gradle では、デフォルトの依存関係の解決で最新の依存関係が使用されます。この場合、これは Velocity 1.7 を意味します。

Mavenでは、プロジェクトに最も近い依存関係を使用することで依存関係の解決が達成されます。これは、プロジェクトが Velocity 1.7 への依存関係を宣言しているため、使用されるのはそのバージョンであることを意味します。

どちらのアプローチでも、システム (または ReportNG) が Velocity 1.7 で動作するかどうかは、テストする必要があります。

于 2014-05-19T10:23:03.520 に答える