Frage

In watching some video tutorials on JBoss's Arquillian, I stumbled across another project of theirs called ShrinkWrap (because Arquillian uses it).

After spending some time on their project page, I can't seem to find concrete answers to a few questions, and it seems to be a pretty new (immature) project that doesn't have a big dev community behind it. Specifically:

  • Is the purpose of ShrinkWrap to create in-memory JARs, WARs and EARs? If so, why would I want to do that? If not, what is the purpose of ShrinkWrap and what problem does it solve?
  • Does ShrinkWrap touch the file system (does the JAR actually get created on disk, or is it truly 100% in-memory)? If not, then what's the value of an in-memory archive?

Thanks in advance!

War es hilfreich?

Lösung

One of the advantages of having an in-memory JAR is that you are able to deploy it to a remote JBossAS instance without even having to write it to a file. When you don't write a file, you don't make up silly temp JAR file names, then remember to delete them later, etc..

General point is to have as less dependencies and side-effects on build-environment as possible.

It may seem that the project is immature, but it's not true. The development is very active, and the community is wide, people coming not only from JBoss world, but also from all the major app-server communities!

Andere Tipps

A traditional build process involves writing bytes to disk, which are then read into memory by the application server. This is an unnecessary step if you all you want is to hand your application server of choice your deployment artifact. The application server looks at the artifact as a stream of bytes, it really doesn't matter if the bytes are provided from disk or memory. With ShrinkWrap you can programmatically build your artifacts so there is no need to involve a separate build process.

ShrinkWrap doesn't touch the file system unless you want to. If you want to, ShrinkWrap can easily produce physical archives on disk with the following code:

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

You can also do the opposite, import physical archives from disk into memory.

Arquillian uses ShrinkWrap, but ShrinkWrap itself is definitely not limited to that use case and can of course be independently used however you like. It can be used for e.g. VFS tasks or even be hooked into an existing build process (as demostrated at http://blog.diabol.se/?p=122).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top