Hey Ron, thanks for sharing these details. I created a separate arquillian.xml file for AS7 and JBoss.
https://github.com/apache/deltaspike/commit/ce875fde3fe5421c6d12bd43019fedaee8af5923 I guess this setup should work fine now. Christian 2014-02-04 10:18 GMT+01:00 Ron Smeral <[email protected]>: > Christian, > > I just found out, that adding <protocol type="Servlet 3.0" /> to the > <container> element in arquillian.xml only configures (does not select) an > already selected protocol. If no protocol is selected using > <defaultProtocol>, then the container's default is used. And the default > for AS7 is, sadly, "jmx-as7", which is intended for internal testing of the > container and makes tests unstable. > > What could be done, is to create arquillian-owb.xml in test-utils, and add > <arquillian.xml>arquillian-owb.xml</arquillian.xml> to the > <systemProperties> in OWB profile. Or the other way around for JBoss. > > Ron > > > On 3.2.2014 17:23, Christian Kaltepoth wrote: > >> @Ron >> >> I just tried that. The result is this: >> >> java.lang.IllegalArgumentException: No >> org.jboss.arquillian.container.spi.client.protocol.metadata.HTTPContext >> found in >> org.jboss.arquillian.container.spi.client.protocol. >> metadata.ProtocolMetaData. >> Servlet protocol can not be used >> at >> org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor( >> BaseServletProtocol.java:64) >> at >> org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor( >> BaseServletProtocol.java:35) >> at >> org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter. >> getContainerMethodExecutor(RemoteTestExecuter.java:136) >> at >> org.jboss.arquillian.container.test.impl.execution. >> RemoteTestExecuter.execute(RemoteTestExecuter.java:119) >> >> What if we just add *<protocol type="Servlet 3.0" />* to all the AS7 and >> >> Wildfly profiles? Wouldn't this fix all our problems? >> >> Christian >> >> >> >> >> 2014-02-03 Ron Smeral <[email protected]>: >> >> Hi Christian, >>> >>> the reason for this could be, that in parent/code/pom.xml, the >>> 'org.jboss.arquillian.protocol:arquillian-protocol-servlet' dependency >>> is >>> not declared for any non-JBoss profile (OWB, tomee, glassfish, ..). >>> Could you try it with the dependency declared? >>> >>> Ron >>> >>> >>> On 3.2.2014 10:51, Christian Kaltepoth wrote: >>> >>> @gerhard: >>>> >>>> I was getting this when running the build: >>>> >>>> Caused by: java.lang.IllegalStateException: Defined default protocol >>>> Servlet 3.0 can not be found on classpath >>>> at >>>> org.jboss.arquillian.container.test.impl.client.protocol. >>>> ProtocolRegistryCreator.createRegistry(ProtocolRegistryCreator.java:61) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke( >>>> NativeMethodAccessorImpl.java:57) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke( >>>> DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:606) >>>> at >>>> org.jboss.arquillian.core.impl.ObserverImpl.invoke( >>>> ObserverImpl.java:94) >>>> at >>>> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers( >>>> EventContextImpl.java:99) >>>> >>>> The weird thing is that Maven simply doesn't run the tests in this case >>>> which leads to a successful build. >>>> >>>> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 >>>> >>>> Full log of running "mvn clean -POWB -Dowb.version=1.1.8" on core-impl >>>> with >>>> the default protocol entry: >>>> >>>> http://pastebin.com/raw.php?i=1hk9nxmZ >>>> >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> 2014-02-02 Gerhard Petracek <[email protected]>: >>>> >>>> @christian: >>>> >>>>> locally i've tested the owb-, weld- and some build-managed-profiles >>>>> with >>>>> the defaultProtocol you removed and everything is working on my >>>>> machine. >>>>> -> please provide further details. >>>>> >>>>> regards, >>>>> gerhard >>>>> >>>>> >>>>> >>>>> 2014-02-01 Christian Kaltepoth <[email protected]>: >>>>> >>>>> @Ron & @Jason >>>>> >>>>>> The defaultProtocol was only used in a single arquillian.xml file of >>>>>> the >>>>>> >>>>>> 8 >>>>> >>>>> different ones we had before. I had to remove it because the plain >>>>>> Weld >>>>>> + >>>>>> OWB integration tests started to fail with it (at least for me) for >>>>>> some >>>>>> reason. >>>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> >>>>>> 2014-01-31 Jason Porter <[email protected]>: >>>>>> >>>>>> The JMX protocol for Wildfly / AS is horrible and for any sort of >>>>>> >>>>>>> application or framework the servlet adaptor should be used. Yes, >>>>>>> it's >>>>>>> >>>>>>> a >>>>>> little slower, but it will give you the full environment you're used >>>>>> to >>>>>> >>>>>>> using when you develop. >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 31, 2014 at 1:59 PM, Ron Smeral <[email protected]> >>>>>>> >>>>>>> wrote: >>>>>> Hi Christian, >>>>>> >>>>>>> I see you recently removed defaultProtocol from arquillian.xml. Is >>>>>>>> >>>>>>>> there >>>>>>> any reason not to have it there? The now default JMX protocol seems >>>>>>> to >>>>>>> >>>>>> be >>>>>> >>>>>> causing test stability issues, I can't succesfully run for example >>>>>>> the >>>>>>> >>>>>> Data >>>>>> >>>>>>> module tests. I'm not sure why this happens. Have you maybe >>>>>>>> >>>>>>>> encountered >>>>>>> >>>>>> this too? >>>>>> >>>>>>> Also, just FYI, we now have a job 'DeltaSpike-wildfly-daily' at >>>>>>>> hudson.jboss.org which tests the wildfly-build-managed profile. It >>>>>>>> >>>>>>>> will >>>>>>> be sending mails to commits@deltaspike. >>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> On 25.1.2014 08:36, Christian Kaltepoth wrote: >>>>>>>> >>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> >>>>>>>> Ron Smeral >>>>>>>> JBoss Quality Engineer >>>>>>>> Brno >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Jason Porter >>>>>>> http://en.gravatar.com/lightguardjp >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Christian Kaltepoth >>>>>> Blog: http://blog.kaltepoth.de/ >>>>>> Twitter: http://twitter.com/chkal >>>>>> GitHub: https://github.com/chkal >>>>>> >>>>>> >>>>>> >>>> -- >>> 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
