Hey all, I pushed out all the changes of the "build-managed" integration test Maven profiles which I suggested.
You can now run the integration test suite against the different containers like this: $ mvn clean install -Ptomee-build-managed $ mvn clean install -Pjbossas-build-managed-7 $ mvn clean install -Pwildfly-build-managed $ mvn clean install -Pglassfish-build-managed-3 $ mvn clean install -Pglassfish-build-managed-4 Each profiles will automatically download, unpack and configure the corresponding container. All TCP ports are changed so that they differ from this default ones. This way we should be able to run them on the CI server without any problems. Could anyone with the required permissions add corresponding jobs in Jenkins? Christian 2014/1/11 Christian Kaltepoth <[email protected]> > 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 > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
