1

JBoss の Arquillian に関するいくつかのビデオ チュートリアルを見ているときに、ShrinkWrapと呼ばれる彼らの別のプロジェクトに出くわしました (Arquillian が使用しているため)。

彼らのプロジェクトページにしばらく時間を費やした後、私はいくつかの質問に対する具体的な答えを見つけることができないようであり、背後に大きな開発コミュニティを持たないかなり新しい (未熟な) プロジェクトのようです. 具体的には：

  • ShrinkWrap の目的は、メモリ内の JAR、WAR、および EAR を作成することですか? もしそうなら、なぜ私はそれをしたいのですか？そうでない場合、ShrinkWrap の目的は何ですか? また、ShrinkWrap はどのような問題を解決しますか?
  • ShrinkWrap はファイル システムに影響しますか (JAR は実際にディスク上に作成されますか、それとも本当に 100% メモリ内に作成されますか)? そうでない場合、メモリ内アーカイブの価値は何ですか?

前もって感謝します！

4

2 に答える 2

7

従来のビルド プロセスでは、バイトをディスクに書き込み、アプリケーション サーバーによってメモリに読み込まれます。選択したアプリケーション サーバーにデプロイ アーティファクトを渡すことだけが必要な場合、これは不要な手順です。アプリケーション サーバーはアーティファクトをバイト ストリームとして認識します。バイトがディスクから提供されたものであるか、メモリから提供されたものであるかは問題ではありません。ShrinkWrap を使用すると、アーティファクトをプログラムでビルドできるため、別のビルド プロセスを必要としません。

ShrinkWrap は、必要な場合を除き、ファイル システムには触れません。必要に応じて、ShrinkWrap は次のコードを使用してディスク上に物理アーカイブを簡単に作成できます。

WebArchive war = getArtifact();
war.as(ZipExporter.class).exportTo(new File("/tmp/myartifact.war"));

逆に、物理アーカイブをディスクからメモリにインポートすることもできます。

Arquillian は ShrinkWrap を使用していますが、ShrinkWrap 自体はそのユース ケースに限定されず、もちろん独立して自由に使用できます。たとえば、VFS タスクに使用したり、既存のビルド プロセスにフックすることもできます ( http://blog.diabol.se/?p=122でデモされているように)。

于 2012-09-12T15:07:08.530 に答える
3

インメモリ JAR を持つ利点の 1 つは、ファイルに書き込む必要さえなく、リモート JBossAS インスタンスにデプロイできることです。ファイルを書き込まないときは、ばかげた一時 JAR ファイル名を作成せず、後でそれらを削除することを忘れないでください。

一般的なポイントは、ビルド環境への依存関係と副作用をできるだけ少なくすることです。

このプロジェクトは未熟に見えるかもしれませんが、そうではありません。開発は非常に活発で、コミュニティは幅広く、JBoss の世界だけでなく、すべての主要なアプリケーション サーバー コミュニティからも参加しています。

于 2012-06-30T17:41:08.537 に答える