Jarのパッケージングと配布

Question

共通のコードが期待どおりにパッケージにレイアウトされています。 これらのパッケージの一部である handler, processor, util, registrationなど

共通は、ここでは、相互に関係のないを投影し、これらが複数のJava/Java EEの間で再利用することを意味します。

質問は配布用にパッケージ化されています。

各パッケージは異なる機能単位を構成しますが、まとめてAPIになります。

個々の機能をJARにバンドルし、8〜10個のジャーで終わらせるべきでしょうか。 例：ハンドラジャー、登録ジャーなど

または

我々は、単一のjarに5つの必修パッケージのベースのビルドで最小公倍数のアプローチを取る必要があります。 他の誰もそのベースをベースとして必要とし、アドオン・ジャーを選択できます。

ビルドシステムはAnt + Ivyであり、これらの依存関係はコンパイル時およびビルド時に解決されます。

Answer 1

APIクラス（Springと思う）がたくさんあるか、またはそれらの間の干渉を認識していない限り、別々のジャーに分割する理由はほとんどないと私の意見です。別々のjarファイルでAPIを無効にする他の唯一の理由は、異なるチームが独立して作業できるようにすることです。

単一のjarを管理すると、多くのことが簡単になり、存在しない問題を修正する価値はありません。

Answer 2

個別のジャーを使用したソリューションが優れています。あなたがmavenを使用していて、各論理コンポーネントがそれ自身のpom.xmlを持っているなら、これは唯一のオプションです。

1つの大きな瓶には、配布が容易であるという利点があります。たとえば、ユーザーがインターネットからjarファイルをダウンロードして手動でインストールすると、多くの場合よりも1つのjarファイルを扱う方が簡単です。しかし、そうでない場合は、マルチジャーのソリューションを使用することをお勧めします。しかし、それぞれのjarファイルにそのバージョンをスタンプすることを忘れないでください。少なくともmanifest.mfファイルにバージョンを入れてください。 Mavenはまた、jarの名前の一部としてバージョンを入れます。これは非常に良い習慣です。

Answer 3

APIは、そうでない場合は、複数のjarファイル

任意のアプリケーションは、utilのと同様に、複数のjarなどの登録を使用したい場合はシングル瓶のメリットを作成mulitpleジャーに優れた巨大な分割がある場合。彼は1瓶だけを入れなければならない。

制限 あなたのjarファイルのサイズはで非常に大きく、あなたはその後、瓶内のみutilのクラスを使用している場合には。アプリケーションのサイズが問題ではない場合は、アプリケーションサイズを大きくする可能性があります。