And as a corallary:

UserCreatedArchiveGenerator:

         if(ClassContainer.class.isInstance(archive)) 
         {
            ClassContainer<?> classContainer = ClassContainer.class.cast(archive);
            classContainer.addClass(testCase);
         }

Why are we adding the test class into the user-specified @Deployment?

S,

ALR

We're headed down the road to opinionated software.

Here's my use case:

@Deployment
public static JavaArchive createDeployment()
{
   return Archives.create("slsb.jar", JavaArchive.class).addClasses(EchoLocalBusiness.class, EchoBean.class);
}

I need that deployed.  I don't want it wrapped with any Arquillian stuff, nor altered in any way.  When we do, it blows up.  It's an exaggeration of the uncertainty principle (and observer effect):

http://en.wikipedia.org/wiki/Observer_effect_%28physics%29

You cannot observe without changing the environment.

This gets down to a design goal: I don't think that the mission of the Arquillian project should be "to run your tests inside a Container".  I think instead it should be "manage container and deployment transparently alongside test lifecycle".

Though running your tests *inside* the container as a deployment is a great feature, I don't think it can be the cornerstone of the project or the default mechanism.  For these reasons:

• When you wrap a user JAR deployment, you change the Global JNDI name of EJBs
• Target containers may not understand what you're giving them
• Assuming the user deployment is an EAR, you wrap it in another EAR?  Uh oh.
• The test, expecting @EJB injection of remote proxies for instance, will skip the remoting layer, and that doesn't get tested
• The user is no longer testing what they expect; I was shocked to see my @Deployment wasn't being passed along unaltered

aslak wrote:

 

This is where the upcoming DeploymentPackager SPI comes into play. Each container could have it's own way of packaging. JBoss and Glassfish support ear/war, OpenEJB some jar struct, Weld SE a Bean Archive..

 

As for now the packaging is handled in only one way, and it assumes a EE ear.

I'll have to see more about this DeploymentPackager, but it sounds scary as a default.  We let the user specify their deployment; that *is* the package.  In the more rare case that you want to run the test as part of the deployment, that to me is an additional feature and separate concern.

Assumptions are fine if they mimick the default or expected behaviour.  And IMO any assumptions you make *must* be configurable by the user to specify what they need.

aslak wrote:

And to answer why you can't just pass your archive to the container.. that works in your embedded container case, but in a local / remote container, we need to add a lot of 'stuff' to the deployment for it to run ie: The Arquillian TestRunner(+ JUnit/TestNG), The Arquillian Core, The protocol for communication with the container, The TestEnrichers for injection in container....

I think you've just laid out a fine case for remoting as an aspect.   The most simple case is direct deployment to a local container.  Just forward it along.  If other containers need special handling, then some chain of wrappers may be necessary.  But the core bits are very simple: take the user deployment and put it into the container.

At present moment I'm blocked with doing OpenEJB integration (and GlassFish too) as I want to change the behaviour currently in place in "DeployableTest" (or not use it entirely), but I don't know what I'll break.  More testsuite coverage will help with that.

S,

ALR

Neat; how can I wire up a no-op DeploymentPackager?  Or are we not quite there yet and this needs more work?

S,

ALR