アプリケーションの起動時にアプリケーションのクラスパスに追加できる 1 つの jar に、提供されているすべての依存関係を sbt でダウンロードしてパッケージ化する方法はありますか?
私は sbt-assembly を使用していますが、生成された jar は私の好みには大きすぎます: Scala-lang、Akka、Spray の両方を含めて 16 Mb です。それぞれがjarとして約10〜15の小さな独立したサービスを構築することを計画しており、新しいバージョンのデプロイを作成するたびに16 Mbのファイルをs3(現在のリポジトリ)にアップロードし続けたくありません。
Scala 言語と上記の他の jar を除外すると、アセンブリ jar は約 1 Mb になります。だから私が達成したいのは、提供された依存関係とscala言語のみを含むfat jarを提供する方法を用意して、サービスを開始するときにそれをサービスのクラスパスに追加できるようにすることです。
Ivy キャッシュから各ライブラリを取得し、それらを手動で展開してクラスパスに追加することもできますが、基本的には、バージョンを変更してアップロードするたびに、新しい組み立てられた jar を構築できるようにしたいと考えています。
提供されたすべてのjarを含む、他のプロジェクトが依存する別のプロジェクトを用意することを考えましたが、もっと簡単な方法はありますか?
要求に応じてさらに明確にする:
私のより大きな目標は、クラウド サーバーへの自動展開です。最初に sbt-assembly を使用してローカルでビルドします。たとえば、service-a.jar、service-b.jar などを生成します。次に、これらを s3 に同期します。そのため、service-a.jar のみが更新された場合、そのファイルのみがアップロードされます。 s3。次に、変更されたファイルをダウンロードし、新しいサービスを再起動するように ec2 サーバーに指示します。
sbt-assembly を使用すると、すべての依存関係を含むファット jar (onejar と同様) が得られます。ただし、その jar を s3 にアップロードするには時間がかかり、16Mb のファイルのうち 15Mb は一般的な依存関係にすぎません。したがって、私の考えは、これらすべての共有依存関係を、めったに変更されない別の jar に入れ、起動時にクラスパスにそれらを提供することjava -cp "deps.jar;service-a.jar" org.myapp.StartApp
でした。
これらの一般的な jar を自分で手動で管理したくありません。既存のビルドを活用し、sbt/ivy 依存関係管理システムを使用して正しいファイルをダウンロードし、スタンドアロン サービスとは別に配布できるパッケージを準備したいと考えています。
これまでに思いついたすべての解決策は、特にテストなどを実行できる必要がある場合 (したがって、sbt ビルド ファイルで "提供" されていない場合) は、これまでのところ非常に複雑に思えます。他の提案は大歓迎です。