Hey Ron, yeah, there are differences between arquillian.xml files. But why? I don't see any reason for having different arquillian.xml files between modules. Actually the integration test Maven profiles are also located in a single parent pom and not in each individual module pom. IMHO we should treat arquillian.xml the same way. Unless there is a good reason for having multiple ones.
I agree that we should unpack the container only once. I'm not sure I like to use java.io.tmpdir though. It would be nice to have it in the top-level "target" directory or something like that. That would ensure that running "mvn clean" would also remove the unpacked container. Christian 2014/1/2 Ron Smeral <[email protected]> > > On 2.1.2014 17:55, Christian Kaltepoth wrote: > >> Hey all, >> >> there are two things I would like to address regarding our integration >> test >> suite. >> >> 1. Currently each module has its own arquillian.xml file. IMHO this >> doesn't >> make sense. What about using a single arquillian.xml and placing it in the >> test-utils module? >> > +0, there are minor differences among them currently (though not sure if > necessary), and it would make it more difficult to make an individual > modification if there was single arquillian.xml. > > >> 2. We have both "managed" and "remote" profiles for some containers. But >> the "managed" profiles (especially Wildfly + Glassfish) require you to >> manually download and setup the corresponding container which I would like >> to avoid. I think it would be nicer if the "managed" profiles could do >> this >> automatically. This would simplify the process of running the tests >> locally >> before committing and it would also be easier to create CI jobs for them. >> See [1] for an example of a profile which sets up the container >> automatically and therefore runs out of the box even in transient CI >> environments like Travis [2]. >> > There already is such profile at least for JBoss AS7 > (jbossas-build-managed-7) and at this very moment I'm adding such profile > for WildFly. However, currently there is a minor drawback to the current > approach -- the container is unpacked for every module and so almost 5 GB > of diskspace is required to run the whole testsuite, which is quite > impractical. It would be nice to have the container unpacked to a shared > location, e.g. ${java.io.tmpdir}, just as in the ocpsoft rewrite pom you > linked. I'll try that in the AS7 and WF8 profiles. > > > >> Thoughts? >> >> [1] https://github.com/ocpsoft/rewrite/blob/master/pom.xml#L706 >> [2] https://travis-ci.org/ocpsoft/rewrite/builds/16192940 >> >> Christian >> >> >> -- > Ron Smeral > JBoss Quality Engineer > Brno > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
