クライアントライブラリに依存ライブラリを提供する必要がありますか？

Question

GoogleのアプリのREST APIに接続するための他の内部アプリ用のクライアントジャーを提供しています。私たちのAPIは、いくつかの標準的なJakartaライブラリに依存しています。これらのJARファイルをクライアントjarファイルに含めることがベストプラクティスですか？あるいは、依存関係を文書化するだけで、クラスパス上にそれらのjarファイルがあることを確認するのはクライアントの責任ですか？

Answer 1

あなたははユーバージャーとして、独自のjarファイルに任意のサードパーティのjarファイルをバンドルするべきではありませんが、あなたのディストリビューションで必要とされているすべてのjarファイルのlibディレクトリに言うか、何のコピーを含めることが良いでしょうこれまで

主な理由は、クライアントがある種の依存関係管理システム（maven/ivyなど）を使用している可能性があり、プロジェクトに実際に属していないパッケージとクラスを提供するとこれらのスキームが無効になることです。

代替方法が1つあります。これは、maven shade pluginのようなものを使用して、依存関係を独自のパッケージ名前空間に再配置することです。これにはもちろん、ライブラリのコードサイズを増やすという側面がありますが、クライアント側で依存関係のバージョンを保証することができます。

EDIT：移転外バンドルと

可能なソリューション/：：マーカス・レオンのコメントに応じて

• ドキュメント、あなたの依存関係と、以前のバージョンとの任意の既知の競合を文書化することを確認してください - 誰もいません実際にそれを読む
• 依存関係管理されたシステムを介してライブラリを配布します.Mavenまたはivyリポジトリのように、依存関係が何であるかという非常に特定の範囲（上限を含む）で文書化することができますのみ有用あなたの依存関係がMavenを使用して構築されたかがマニフェストファイルにバージョン情報を持っている場合は、あなたのクライアントは、実際のOSGi
• を使用する場合 - 上書きちょうどあなたのクライアントは、MANIFEST.MFにOSGiの情報を追加し、彼らは
• それをやっていることを知っているだろうあなたはこれらのクラスパスをスキャンし、バージョンをチェックする何らかのチェックルーチンを書くことができます - 極端なビット数

最終的には、実際にあなたが依存関係を確実に確保するのは非常に困難です。クラスパス上であなたの前に異なるバージョンを含む誰かによってあなたの依存性（バンドルされていても）を上書きすることは可能です。

注：私は最近、を非常にという悪い日に使って、なぜアプリケーションの1つが新しいバージョンのlog4jを見つけられなかったかを調べようとしました。原因：誰かが助けようとしている人は、それを無関係な完全に無関係なジャーに束ねていた。

Answer 2

スタンドアロンアプリケーションとしてアプリケーションをデプロイする場合は、これらのjarファイルを含める必要があります。誰かがビルドするためのソースをデプロイしていて、maven pomファイルを提供している場合、必ずしもそうする必要はありません。

Answer 3

あなたが依存しているジャーを含めてください。クライアントが標準のjarファイルを提供できるようにする場合は、正しいバージョンを提供するために依存します。あなたのアプリケーションが動作することが分かっているバージョンを含めると、どちらの方もずっと痛いことになります。

Answer 4

単一ジャーに同梱の長所は明らかにされている：束ねるのクライアントのための

• シンプル

短所は以下のとおりです。のバージョンを更新する

• できないこと依存ライブラリー
• 必要なライブラリーを隠すことで、実際にクライアントの潜在的な競合につながる可能性がありますビルドプロセス中にあなたのための時間、それらの余分のライブラリ
• 複雑（しかし、アリ/ Mavenの中ではかなり簡単にこれを行う方法）
• マニフェストを持ついくつかのライブラリはちょうどunjaredとrejaredすることはできません - あなたが実際にマニフェスト情報をマージする必要があります。しかしこれにはAntとMavenのサポートがあります。

もう1つの方法は、class-pathマニフェスト属性が1つのメインjar（コード）を使用して、他のjarファイルを吸い込むことです。個人的には、これらの半隠れた依存関係を見逃すことは本当に簡単なので、私はこれが気に入らない。

ちょうど1つか2つのジャーを話しているならば、私はそれらを分けて残しておきます。あなたが10か15の話しをしているならば、バンドルを検討したいかもしれません。

Answer 5

非常に具体的なライブラリのバージョン依存性については緊張しています（Hibernateがさまざまなモジュール間でどのくらい緊密に結合されているかを考慮すると、あるバージョンのHibernateアノテーションのみが1つのhibernate-core特定のhibernate-validatorとともに使用する必要があります）。

もっと大きなプラットフォーム（例えば、独自のjarをロードするフレームワークのプラグインとして）としてパッケージを動作させる必要がある場合は、より強力な複数バージョンのクラスロードが必要です。 OSGI（別名JSR-291）： OSGI Technology

OSGI対応のフレームワークでは、春、Eclipseの、ジョナス、またはGlassfishのように、あなたがあなたの特定のバージョンの依存ファイル、XMLで指定することができ、そしてあなたは、バンドルに依存している場合libfoo-1.1.4、もう1つのプラグインはlibfoo-2.0aに依存しますが、OSGI依存マネージャーはそれぞれが正しいバージョンをロードするようにします。