Re: Optimizing the integration tests

2014-02-07 Thread Christian Kaltepoth
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 : > Christian,

Re: Optimizing the integration tests

2014-02-04 Thread Ron Smeral
Christian, I just found out, that adding to the element in arquillian.xml only configures (does not select) an already selected protocol. If no protocol is selected using , then the container's default is used. And the default for AS7 is, sadly, "jmx-as7", which is intended for internal tes

Re: Optimizing the integration tests

2014-02-03 Thread Christian Kaltepoth
@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.arqui

Re: Optimizing the integration tests

2014-02-03 Thread Ron Smeral
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, Chr

Re: Optimizing the integration tests

2014-02-03 Thread Christian Kaltepoth
@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.ja

Re: Optimizing the integration tests

2014-02-02 Thread Gerhard Petracek
@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 : > @Ron & @Jason > > The defaultProtocol was only u

Re: Optimizing the integration tests

2014-02-01 Thread Christian Kaltepoth
@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 : > The JMX pro

Re: Optimizing the integration tests

2014-01-31 Thread Jason Porter
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 wrote: > Hi Chri

Re: Optimizing the integration tests

2014-01-31 Thread Ron Smeral
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 may

Re: Optimizing the integration tests

2014-01-24 Thread Christian Kaltepoth
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 > hi christian, > > the jenkins-jobs should be in place already. > > regards, > gerhard > > > > 2014/1/24 Christian Kaltepoth > > > Hey all,

Re: Optimizing the integration tests

2014-01-24 Thread Gerhard Petracek
hi christian, the jenkins-jobs should be in place already. regards, gerhard 2014/1/24 Christian Kaltepoth > 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 differe

Re: Optimizing the integration tests

2014-01-23 Thread Christian Kaltepoth
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 cle

Re: Optimizing the integration tests

2014-01-11 Thread Christian Kaltepoth
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 > Hey Christian, > > you're right, I haven't realized that. Also, if some mo

Re: Optimizing the integration tests

2014-01-08 Thread Ron Smeral
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 "

Re: Optimizing the integration tests

2014-01-07 Thread Christian Kaltepoth
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 ar

Re: Optimizing the integration tests

2014-01-07 Thread Ron Smeral
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 Effectiv

Re: Optimizing the integration tests

2014-01-06 Thread Christian Kaltepoth
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 M

Re: Optimizing the integration tests

2014-01-03 Thread Ron Smeral
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

Re: Optimizing the integration tests

2014-01-03 Thread Gerhard Petracek
@christian: +1 (@as7: sounds like a missing cleanup, like it's done for tomee) regards, gerhard 2014/1/3 Christian Kaltepoth > 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. >

Re: Optimizing the integration tests

2014-01-02 Thread Christian Kaltepoth
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 t

Re: Optimizing the integration tests

2014-01-02 Thread Ron Smeral
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-

Optimizing the integration tests

2014-01-02 Thread Christian Kaltepoth
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? 2. We have both "managed" and "rem