After playing with Arquillian and shrinkwrap for a short while I wanted to mention a few issues that have come up so far,
At least as far as Arquillian goes, is the idea to just dump all classes into the test case or is there a benefit to only including classes that you need for a given test? Should we be just adding our root level packages and leaving it up to shrinkwrap to pull everything in?
Tests seem to have a 'core' configuration (beans.xml,persistence.xml, key classes) and the tests have a variety of additional configuration depending on the test being run. If we are not taking the kitchen sink approach and adding everything then there are times when you want to change the content of the archive depending on the test.
Regarding configuration files, I know you have the DSL for descriptors project going which is looking good, but ignoring that for a moment, there is the possibility that different tests needs different elements within a file. For example, turning decorators, alternatives and interceptors on and off while keeping the rest of the file the same for different tests. Tests may also need to be run multiple times with subtle archive changes.
For Arquillian, this also brings up the question of how the deployments are defined. Do we use one big master archive to use in the @Deployment methods for every test or write one per test class which raises DRY issues?
The reason I'm asking this because I wrote a little wrapper for ShrinkWrap that lets you build a graph of all the elements in the deployment and then build the archive from that using shrinkwrap. It handles profiles so you can assign profiles to nodes so they are only included when a profile is enabled. Profiles can also be used to exclude nodes, so you can say "use this node by default unless this profile XYZ is set, and use this alternative if profile XYZ is set". This can come in handy if you have to create separate implementations for different sites. You can create a profile for that site and it will include/exclude nodes in the final archive.
It also lets you create files from multiple file fragments so you can build a file from multiple nodes which combined with profiles means you can have a file with different content depending on the tests being run (i.e. enable different alternatives based on the profiles being run).
Additionally, it also lets you add a class and it will use reflection on the class to add all dependencies.
However, its another layer on top of ShrinkWrap that really just does a little more than ShrinkWrap does. I know shrinkwrap is a low level API, but does it need a higher level API or are you planning on adding more sophisticated features or is that out of scope. Shrinkwrap does the heavy lifting for building archives, while Arquillian handles the testing, but it seems like it needs something to help bridge the two.
The only real missing features are :
Adding classes with dependencies (not necessary if using the kitchen sink approach of adding top level packages)
Conditional inclusion in archives based on profiles
(optional) Multi-fragment files (not sure how the Descriptor DSL fits in here, but not all files will have a DSL)
This project works ok for me right now, I'm just trying to get a feel for whether this is something you are planning on adding, or whether it is worth investing the time and effort to polish it up a bit, even just to release it as an alpha build to get some feedback and see if it is something that people might use.
I blogged about the very alpha version with some snippets
The code is also available for download. Looking at it, it really depends on whether Shrinkwrap is going to expand with concepts like profiles.