You could take a look at what Dan and I did for native owb: https://github.com/struberg/arquillian-container-openwebbeans LieGrue, strub
----- Original Message ----- > From: Jonathan Gallimore <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, October 5, 2011 12:57 AM > Subject: Re: Arquillian adapters > > On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore < > [email protected]> wrote: > >> >> >> On Thu, Sep 29, 2011 at 12:01 AM, David Blevins > <[email protected]>wrote: >> >>> >>> On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: >>> >>> > When I hacked up the Remote with zip adapter I intended to >>> > merge it into the remote adapter - along the lines of: check to > see if >>> TomEE >>> > is running on the port specified in arquillian.xml. If it is, just >>> deploy >>> > straight to it. If not, go grab the zip and use that. Does that > sound >>> like a >>> > reasonable idea? >>> >>> Very reasonable. That's what the itests have done for years, the > CDI TCK >>> does and the Java EE TCK setup does. >>> >>> It's pretty easy to have the rule of "if you don't want us > to start a >>> server, make sure a server is started" >>> >> >> Cool, I'll get that done. >> > > I've extended the remote adapter to allow this. If you specify something > like (note the 1.0.0-beta-1 OpenEJB version and no Tomcat version): > > <arquillian > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd";> > <container qualifier="tomee" default="true"> > <configuration> > <property > name="dir">/tmp/arquillian-apache-tomee</property> > <property name="httpPort">9080</property> > <property name="stopPort">9005</property> > <property name="tomcatVersion"></property> > <property > name="openejbVersion">1.0.0-beta-1</property> > </configuration> > </container> > </arquillian> > > if nothing is running on port 9080 we'll download TomEE, unzip it, start it > and use that for the test. > > If you changed the OpenEJB and Tomcat versions to, say: > > <property > name="tomcatVersion">7.0.21</property> > <property > name="openejbVersion">4.0.0-beta-1</property> > > We'd download Tomcat and the OpenEJB.war, set that up, and use that instead. > So we should be able to use this to test against Tomcat 5.5/6 with OpenEJB. > > I quite like this, but it would be great to get any feedback. > > >> >> >>> >>> > That leaves the embedded-with-war adapter as something that might > seem a >>> bit >>> > odd. Currently I can't get it to run correctly, but that might > be >>> something >>> > wrong with my machine. What's people's opinion of this > method? Should we >>> > drop this, or is it a useful adapter to hang on to? >>> >>> My impression is I would never ever advise a user to use it. That > said, >>> it's an absolutely fabulous way for us to test the drop-in-war >>> functionality. Well, almost fabulous... the real world scenario is an >>> existing Tomcat install, not an embedded one. >>> >>> Either way, if we say to people "you can do this and it > works!" having an >>> adapter for it us a must. Especially if we get things to the point > where we >>> can easily reuse the full set of tests on each adapter. At that point > we >>> just need to hook up each adapter with a buildbot builder and suddenly > we >>> have a dreamlike level of testing for the various features we offer. >>> >> >> We shouldn't have any issues getting the tests to run on all the > adapters. >> Worst case we can use Maven profiles and run the tests against the embedded >> adapter by default, and you just switch profile to use the other modes. The >> buildbot builders can then presumably be setup with the necessary profile >> switch in their build. >> >> I was thinking it would be cool to try and extend either the test suite or >> the Arquillian test runner somehow so the test then runs against all the >> adapters in one go. >> >> I was going to do the Maven profile bit first, as that should be reasonably >> straightforward, and then take it from there. >> >> > > I've done some refactoring around the Arquillian test suite, so the tests > now run against both adapters. Currently we have ~6 failures and 2 errors > for both adapters, and it should be the same tests in both cases. We > currently run 82 tests. > > This was a pretty bug refactor - it seemed like things worked well in the > embedded case, because everything is right there on the classpath. Running > remotely a lot of tests failed as they relied on the test or junit being > available from the app being tested. I've separated the inner classes out, > divided things up into packages and tried to move a couple of methods to > trim what would need to be added to the Shrinkwrap archives. We still need > junit in a couple of cases, so in a couple of places we add that in as a > lib. Hope that's all ok. There's probably some duplicate classes we > could > chop out. > > Running the tests can be done by running the test Maven goal in the > arquillian-tomee-tests module. Choosing which adapter to use is done by > enabling a Maven profile. By default we run against the embedded adapter > (arquillian-tomee-embedded). Doing a 'mvn -Parquillian-tomee-remote clean > install' will build and test against the remote adapter. If you're using > an > IDE plugin such as m2e, you should be able to specify the desired Maven > profile in your IDE settings and the tests should run straight from the IDE > (works for me in Eclipse) - please shout if you have trouble, I'll be more > than happy to help! > > Jon >
