デプロイされたアプリケーションがどのように見えるかを確認できるように、アーカイブファイル(EAR、JAR、WAR)にソースコードを含めることを検討していました。これは明らかにアーカイブをはるかに大きくします。アーカイブファイルのサイズは、アプリケーションサーバーのパフォーマンスにまったく影響しますか?これは良い考えですか?
2 に答える
代わりに(ソースを.jarに入れる)またはそれに加えて発生する可能性のある問題の別の解決策は次のとおりです。ソース管理リビジョンIDを.jarに指定します。マニフェストファイルまたはプロパティファイルで指定できます。
ソース管理リビジョンIDは、ソース管理システム上のプロジェクトのルートに関連付けられている現在のIDです。SVN、Git、および最新のソース管理システムですぐに利用できます。古いシステム(CVS)では、おそらく現在の日付と時刻を使用して(名前付き)タグを最初に作成する必要があります(一意性を確保するため)。リビジョン番号を使用すると、アーカイブが取得された正確なスナップショットをソース管理から取得できるため、バグを修正すると、正しいソースで修正されます。
この手法により、スペースを節約できます。ソースディレクトリ全体を出荷する必要はありません。
ただし、ソースがアーカイブに含まれている場合でも、アーカイブが作成された履歴内のポイントを満場一致で指定するという理由だけで、この番号を指定することをお勧めします。アーカイブ内のソースをソース管理内のソースと手動で比較するのは面倒です。
アーカイブのインデックスにさらに多くのエントリがある限り、パフォーマンスに影響しますが、それほど悪くはなく、ソースを独自のサブディレクトリに配置します。または、ソースアーカイブを作成して、他のファイルと一緒にシャベルで移動することもできます。それが私の選択です。もちろん、これがGPLディストリビューションである場合は、ソースがどこにあるかを明示する必要があります。