about our arquillian adapters, do we drop arquillian-tomee-embedded-with-war ? (+1 for me ;))
- Romain 2011/10/5 Jonathan Gallimore <[email protected]> > 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 > >> >
