Hey Ron, yeah, I also thought about using "user.dir", but this could point to some weird locations depending on from where you start the build. So let's go with "java.io.tmpdir" for now.
Christian 2014/1/8 Ron Smeral <[email protected]> > Hey Christian, > > you're right, I haven't realized that. Also, if some module needed a > custom arquillian conf, Arquillian reads a system property named > "arquillian.xml" which defines the name of the configuration file. > > The last thing I can think of for the testsuite root is the Maven property > "user.dir" - the working directory from which mvn was executed. > > Ron > > > On 7.1.2014 17:20, Christian Kaltepoth wrote: > >> Hey Ron, >> >> I don't think unpacking is necessary. If arquillian.xml is located in >> deltaspike/test-utils/src/main/resources, it will be on the classpath for >> all integration tests. That's basically the setup we are using for Rewrite >> since quite some time and it is working fine. See [1]. >> >> I guess you are right regarding the merging of poms and that ${basedir} >> won't work because of this. Too bad. So perhaps we should use >> java.io.tmpdir for now until we find a better way (if there is any). >> >> Christian >> >> [1] >> https://github.com/ocpsoft/rewrite/blob/master/test- >> harness/src/main/resources/arquillian.xml >> >> >> 2014/1/7 Ron Smeral <[email protected]> >> >> Hi Christian, >>> >>> the test-utils is in the parent/code/pom.xml as a dependency, but then >>> still, to get to the arquillian.xml file in the test-utils.jar, it would >>> need to be unpacked using e.g. dependency:unpack plugin goal. >>> >>> Regarding basedir, because POMs are merged in Maven to form the Effective >>> POM, the basedir property always points to the current project, >>> regardless >>> of the POM in which you reference it. >>> For example, if -- as you suggest -- there's project P and C, where P is >>> parent of C, and P contains <root>${basedir}</root>, then for C, the >>> ${root} will contain the base dir of C anyway, not that of P. >>> The least hacky (but still ugly) way that comes to mind is to pass the >>> property an absolute path from the shell, as in "mvn clean test >>> -Droot=$(pwd)". The root property could have a default value of >>> ${java.io.tmpdir}. >>> >>> Ron >>> >>> >>> On 7.1.2014 07:51, Christian Kaltepoth wrote: >>> >>> Hey Ron, >>>> >>>> I don't think we will have to copy arquillian.xml using the >>>> resources-plugin. If we add it to src/main/resources of the test-utils >>>> module, it will be on the test classpath for all other modules. I think >>>> this should work fine. >>>> >>>> Regarding the testsuite root directory. I think we could use Maven's >>>> ${basedir} in the parent pom and store it in a system property. >>>> Thoughts? >>>> >>>> Christian >>>> >>>> >>>> 2014/1/3 Ron Smeral <[email protected]> >>>> >>>> Hi Christian, >>>> >>>>> looking at the arquillian.xml files, they are 99% the same, the only >>>>> one >>>>> that actually differs (other than whitespace, comments and missing >>>>> cdicontainer.version property) is the one in the data module, >>>>> containing >>>>> a >>>>> testDatabase configuration for tomee. So, we could have just one >>>>> arquillian.xml file somewhere in the testsuite root, copy it over using >>>>> resources-plugin, and override it only when necessary. >>>>> One minor problem is -- and this is for the container unpacking too -- >>>>> that to point to the testsuite root, every pom would need to keep a >>>>> relative reference to it (e.g. <testsuite.root>../../..</ >>>>> testsuite.root>), >>>>> which is ugly, but doable. >>>>> >>>>> >>>>> On 3.1.2014 06:26, Christian Kaltepoth wrote: >>>>> >>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>> Ron Smeral >>>>> JBoss Quality Engineer >>>>> Brno >>>>> >>>>> >>>>> >>>>> -- >>> Ron Smeral >>> JBoss Quality Engineer >>> Brno >>> >>> >>> >> > -- > Ron Smeral > JBoss Quality Engineer > Brno > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
