3 Replies Latest reply on Mar 18, 2011 10:51 AM by sperkins

    User Proposal: Don't Require Explicit @Deployment

    alrubinger

      This one came in via Twitter from community contributor Laird Nelson (http://twitter.com/#!/chuggid).  He notes that perhaps we should consider a more automatic mechanism for defining deployments, removing the requirement for the test author to define @Deployment.

       

      Hi; thought I'd put down a few more characters about what I was talking about the other day.

       

      In a big snarling make-you-wanna-weep enterprise Maven project such as the kind I often find myself embroiled in, the pom.xml files are painful enough to put together and maintain.  Once we've listed a zillion dependencies in careful order, complete with exclusions and whatnot, with profiles in the mix and bumbling outsourcers messing up everything overnight, we poor trod-upon enterprise users really don't want to have to regurgitate that information again for unit testing in any form.

       

      So by the time I've gotten my pom.xml file put together, and Surefire configured, and JVM memory parameters set, and...and...the last thing I want to do is any form of fluent or non-fluent classpath construction.

       

      If there were a special Arquillian Maven plugin--which would be necessary, since most Surefire invocations are forked and hence pretty much divorced entirely from the Maven instance that kicked them off--then you could, for example, start life by assuming that I want my classpath the way Maven sets it up.  If Arquillian absolutely, positively has to start life with a ShrinkWrap archive, then such a plugin, perhaps, could create one and stash it away somewhere for retrieval by the Arquillian test runner.

       

      Picture this--and this is just food for thought, not an honest proposal: you have an Arquillian Setup Plugin (whatever) that fires right before Surefire.  Its job unless otherwise configured is to scan the classpath, find likely looking EJB modules, persistence units, and all the other Java EE flotsam and jetsam.  Serialize whatever information it needs to a temp area somewhere.  Presumably this would basically be the deployment archive that would be used unless a test actually declares one of its own.  Push that on the stack for a sec.

       

      Next, Surefire comes along as usual.  It's set up to fork, so it does.  Push that.

       

      Now I've got my test annotated with some kind of enhanced Arquillian test runner that knows about the Arquillian Setup Plugin.  It first checks my test case to see if there's a deployment archive declared.  No?  OK, no worries, it then checks to see if the Arquillian Setup Plugin has left any droppings behind.  Oh!  Look!  There's one!  So it uses that as the deployment archive, or as a starting point for the deployment archive, or...you see where I'm going?  I didn't have to isolate anything myself, configure anything--my pom.xml is the only thing I have to wrestle with as far as classpaths are concerned.

       

      Such a setup plugin would of course make all sorts of assumptions--and that's fine!  I love assumptions as long as they're well documented.

       

      Anyhow, that's what I mean by simple.  I'm well aware there are ALL SORTS of other cases that Arquillian handles, but it's tough to convince a bunch of people to use it when in order to write a test case I have to first start by putting together an archive--even if ShrinkWrap makes that process (relatively) easy.

       

      Thanks for soliciting input and for the work on the project.

       

      Best,

      Laird

       

       

      Thoughts from the community and developers?

       

      S,

      ALR

        • 1. Re: User Proposal: Don't Require Explicit @Deployment
          kpiwko

          I would like to see a feature like that in Arquillian as well. Basically, if we go Arquillian Maven Plugin way, we might bound it to a phase where resources and classes are already compiled (such as process-test-classes) and use SW-140 to grab required dependencies from pom.xml and construct the application archive of appropriate type (JAR,WAR,EAR).

           

          However, this is rather a bit special use case, because I can't see a way how to limit archive to contain only a subset of test classes, basically this will always create a full-featured archive. This is most useful for functional testing in my point of view.

           

          I'd rather propose having @MavenDeployment annotition (with reasonable defaults), which simply make Arquillian construct deployment archive using information in the pom.xml. This is more useful, because it might be combined with another @Deployment, such as JMS Descriptor and so on.

           

           

          @RunWith(Arquillian.class)
          @MavenDeployment(file="pom.xml", profiles = {"foo", "bar"})
          public class MyMavenTest {
          
               @Deployment 
               public static Descriptor jms() 
               {
                    return Descriptors.create(JmsDescriptor.class);
               }
          }
          
          • 2. User Proposal: Don't Require Explicit @Deployment
            alrubinger

            Related discussion:

             

            http://community.jboss.org/message/593950

             

            I'll ping back here with some thoughts soon.

             

            S,

            ALR

            • 3. User Proposal: Don't Require Explicit @Deployment
              sperkins