Will do (will be tomorrow now, its getting late for me!), thanks for the link!
Jon On Oct 5, 2011 12:02 AM, "Mark Struberg" <[email protected]> wrote: > 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 >>
