I was chatting to Aslak today about the Arquillian lifecycle. I still think we've got it a bit upside down - but it looks like no one knew I thought this ;-) I think this is the reason why we are struggling with a number of things - ALRs complaint that Arquillian is fiddling with his archives, the problems with actually doing intelligent defaults for deployment, the difficulty in adding stuff to the resulting deployment etc.
At the moment, Arquillian calls the @Deployment method, takes whatever the user outputs, does some magic (do we have a list of the rules?), and then sends it off to the container. I think we should invert two of these steps, such that the lifecycle becomes:
- Arquillian creates a Shrinkwrap archive containing the magic - the support clasess it needs for the current deployment scenario 
- It calls the @Deployment method, injecting the archive created in (1) as the only parameter
- The user then can add stuff/remove stuff from/to the deployment however they like , and returns it from the method. They can alternatively call Shrinkwrap themselves to create a new archive, ignoring the Arquillian magic.
- Arquillian then deploys whatever the user returns, unmodified.
 Arquillian inspects the declared type of the parameter of the @Deployment method to establish what sort of archive to create. Typically, someone is going to use either WebArchive or EnterpriseArchive I think
 There is some interesting problems with this approach, for example, if the user selects EarArchive, then how do we allow them easily to get to the ejb-archive and web-archive Arquillian populates the EarArchive with? Some thoughts on this later.
Some examples (on pastebin, as there is no sane way to put code on this forum)
Now, we have a much more flexible way to address a few of the issues we currently have:
- When ALR wants to ignore Shrinkwrap magic, he just returns his own Archive. This is a obvious (you can see it in the code), and simple
- When Matt wants to deploy multiple things at the same time (e.g. a standalone ejb-jar and a war), we can easily enhance Arquillian to allow returning a collection of Archives, each one of which will be deployed without running into thorny questions about which is *the* artifact to enhance
- When I want to create a really complex deployment, it's easy to work out what is going on (e.g. Nik today asked why if he creates an Ear, the Test class is omitted - this is completely counterintuitive today, but with this scheme above, it's obvious)
I'll follow up with a post about how you can then configure the defaults for your @Deployment