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,
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
@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
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
@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
@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
@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
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
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
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,
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
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
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
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 "
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
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
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
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
@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.
>
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
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-
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
22 matches
Mail list logo
