他の内部アプリがアプリの REST API に接続するためのクライアント jar を提供しています。私たちの API は、いくつかの標準 Jakarta ライブラリに依存しています。これらの JAR ファイルをクライアントの jar ファイルに含めることはベスト プラクティスですか? または、依存関係を文書化するだけで、クラスパスにこれらの jar があることを確認するのはクライアント次第ですか?
5670 次
5 に答える
14
サードパーティのjarをuberjarとして独自のjarにバンドルしないでください。ただし、配布に必要なすべてのjarのコピーをlibディレクトリなどに含めるとよいでしょう。
これの主な理由は、クライアントが何らかの形式の依存関係管理システム（maven / ivyなど）を使用している可能性があり、実際にはプロジェクトに属していないパッケージとクラスを提供すると、これらのスキームが無効になるためです。
代替案が1つあります。それは、Mavenシェードプラグインのようなものを使用して、依存関係を独自のパッケージ名前空間に再配置することです。もちろん、これにはライブラリのコードサイズを大きくするという欠点がありますが、利点としては、クライアントが使用している可能性のある他のライブラリに影響を与えることなく、依存関係のバージョンをほぼ保証できます。
編集：マーカスレオンのコメントに応えて：
バンドル/再配置なしで可能な解決策：
- ドキュメント、依存関係と以前のバージョンとの既知の競合をドキュメント化するようにしてください-誰も実際にそれを読んでいません
- 依存関係管理システムを介してライブラリを配布します...mavenやivyリポジトリのように、これらを使用すると、依存関係が何であるかを非常に特定の範囲（上限を含む）で文書化できます。それをやっています
- MANIFEST.MFにOSGi情報を追加します-クライアントが実際にOSGiを使用している場合にのみ役立ちます
- 依存関係がMavenを使用して構築されているか、マニフェストファイルにバージョン情報がある場合は、クラスパスをスキャンしてバージョンをチェックする、ある種のチェックルーチンを作成できます-少し極端です
最終的に、Javaはレイトバウンド言語であるため、必要な依存関係があることを実際に確認することは非常に困難です。クラスパスの前に別のバージョンを含む誰かが依存関係をオーバーライドする可能性があります。
Note: I've recently spent a very bad day trying to find out why one of our apps failed to find a new version of log4j. the cause: somebody trying to be helpful had bundled it into a random completely unrelated jar.
于 2009-11-17T08:10:44.160 に答える
7
依存するすべての jar を含める必要があります。クライアントが標準の jar を提供することを許可する場合、正しいバージョンを提供するためにそれらに依存します。アプリが動作することがわかっているバージョンを含めると、両方にとってはるかに簡単になります。
于 2009-11-17T03:34:10.147 に答える
4
単一の jar にバンドルすることの長所は、明らかに次のとおりです。
- クライアントにとってのシンプルさ
バンドルの短所は次のとおりです。
- 依存ライブラリのバージョンを更新できない
- 必要なライブラリを非表示にすると、実際にはクライアントでそれらの余分なライブラリとの競合が発生する可能性があります
- ビルド プロセスにおける複雑さ (ただし、Ant/Maven でこれを非常に簡単に行う方法)
- マニフェストを含む一部のライブラリは、単に unjar および rejar できないため、マニフェスト情報を実際にマージする必要があります。ただし、これには Ant と Maven のサポートがあります。
もう 1 つのオプションは、class-path マニフェスト属性が他の jar を吸い込むように設定された単一のメイン jar (コード) を使用することです。個人的には、これらの半隠された依存関係を見逃すのは本当に簡単なので、これは好きではありません。
最後に、1 つまたは 2 つの瓶だけを話している場合は、分割したままにしておきます。10 または 15 について話している場合は、バンドルを検討することをお勧めします。
于 2009-11-17T04:10:41.960 に答える
2
アプリをスタンドアロン アプリケーションとしてデプロイする場合は、これらの jar を含める必要があります。誰かがビルドするためにソースをデプロイしていて、maven pom ファイルを提供している場合は、必ずしも必要ではありません。
于 2009-11-17T03:10:38.717 に答える
0
あなたは非常に特定のライブラリバージョンの依存関係について神経質になっています（たとえば、Hibernateが異なるモジュール間でどれほど緊密に結合されているかを考えると、Hibernateアノテーションの特定のバージョンのみが1つのhibernateコアで機能します。特定のHibernate-validatorと一緒に使用する必要があります）。
パッケージがはるかに大きなプラットフォームの一部として機能する必要があることがわかっている場合（たとえば、独自のjarをロードする可能性のあるフレームワークへのプラグインとして）、OSGI（別名JSR）のより強力なマルチバージョンのクラスロードが本当に必要です。 -291）： OSGIテクノロジー
Spring、Eclipse、Jonas、GlassfishなどのOSGI対応フレームワークでは、XMLファイルで特定のバージョンの依存関係を指定できます。バンドルlibfoo-1.1.4に依存する場合は、別のプラグインがlibfoo-2.0に依存します。 a、OSGI依存関係マネージャーは、それぞれが正しいバージョンをロードすることを確認します。
于 2009-12-03T20:31:23.060 に答える