Hey Gerhard, yeah, I wasn't aware that the Glassfish jobs have already been added. But Wildfly is still missing.
Christian 2014/1/24 Gerhard Petracek <[email protected]> > hi christian, > > the jenkins-jobs should be in place already. > > regards, > gerhard > > > > 2014/1/24 Christian Kaltepoth <[email protected]> > > > 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 > > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
