Wrap it Yourself

The holiday season is approaching. Since Sam Summer turned into Sam Oktoberfest[1] I’ve seen a frightening array of tinsel slowly invade area department stores, and I know that some dreaded chorus of electronic carols cannot be far behind. But it’s not the commercialism that concerns me. It’s not the burden of shopping, the endless pursuit of parking, nor the $400 doll that some daytime talk show turned into the must-have accessory for our nation’s toddlers. Once I’ve accounted for everyone on my “Good” list…it’s time to sit down and do the wrapping.

The scissors. The tape. Silly cards that unnecessarily explain, “Hey, this is a gift.” It’s not enough that I’ve spent my time considering what you’d like before building or acquiring it; you, princess, need a shiny cover too. Ungrateful bitch.

Application servers are similarly prissy. By specification, they might not have a clue what to do with your programs unless you’ve got cutesy little descriptors littered exactly where they’re expecting. Annotation support introduced in JEE5 helps by reducing the amount of boilerplate XML, but there’s some other implicit metadata within archives. ClassLoading scope says that every resource within a bundle will be able to see each other, and atomicity guarantees that we’ll be treated as a singular deployment.

Traditionally, we have a build process responsible for packaging our resources in expected form. The problem this presents is that our development cycle must look like:

* Code
* Build Step – Compilation
* Build Step – Packaging
* Test

In practice, most IDEs offer incremental compilation which we’ll often overwrite or ignore during the build process. But the most egregious flaw in this setup is the context switching it imposes; you must redirect your attention from the code to run a build. I want to code, test, code, test. Because I’m a very poor coder prone to making mistakes, I test nearly every method for coverage as it’s written.

Scripting the build is a PITA as well. I’m constantly looking at Ant or Maven documentation to figure out the correct syntax. Again, because I’m a poor coder and have low retention for rote tasks. I don’t think it’s a tremendous leap to assume that Java programmers are most proficient in Java. Any context switching we do is distracting. Code, test, code, test.

So we should be writing our tests in Java, without any dependencies on a build process.

The ShrinkWrap[2][3] project enables you to do just that.

// Make an archive; put some classes in there JavaArchve archive = Archives.create("myejb.jar", JavaArchive.class).addClasses(MyLocalBusiness.class, MyBean.class); // Deploy into EmbeddedAS server.deploy(archive); // Log out the full contents in an "ls -l" -type output archive.toString(true); // Export to an InputStream in ZIP/JAR format InputStream in = archive.as(ZipExporter.class).exportZip();

Ultimately, I wanted to continue the support for “manual deployment of archives” pioneered by Bill Burke[4] within EmbeddedJBoss[5]. Previously we used to provide this by leveraging JBoss Virtual File System (VFS)[6] and its in-memory files. After some further consideration we were able to skip *all external library dependencies*. We have a great mission and featureset:

* Intuitive, clean API
* Export to ZIP/JAR or exploded directory
* Import from ZIP/JAR or exploded directory
* Typesafe specialization
* Domain-specific language extensions (To declare web.xml servlet metadata for instance; Under development)

From an administrative standpoint, I can’t be prouder of how this project was run. We took good ideas from history, added some of our own, and collaborated in public with a couple of talented community contributors. Aslak Knutsen[7] and John Bailey[8] in particular gave a lot of their thought and time into ironing out each feature and public interface. We have a testsuite with strong coverage and have used the excellent FindBugs[9] code analysis framework to catch things we didn’t. Jesper Pedersen[10] of JBoss JCA fame gave us a great peer review. And now ShrinkWrap is a first-class citizen in the upcoming release of EmbeddedAS, a new API for the JBoss Application Server. More on that later; watch this space.

Looking forward, I’d love to see some more community involvement; for instance I’ve invited the Glassfish team to consider supporting us in their embedded server.

In the meantime, we’ll be building out our Wiki and documentation. Early-access release 1.0.0-alpha-2[11] was just cut a couple days back, so it’s not too late to give some input before we freeze the APIs[12]. There’s virtually no barrier to entry here; if you know the core JDK you’ll be able to join our development team.

So consider this my holiday present to you. Wrap it yourself.