2:17 p.m.
Hi,
with the latest changes on master, it's now possible to have the new
integration testsuites run against different WildFly versions (till now
they've been using 10.0.0.Final).
The build supports option -Dserver.version=xyz which can be used to tell
it which version of WildFly to download.
Alternatively you could use -Dserver.home=/x/y/z to specify the path to
the container to be used instead of downloading anything (and that can
clearly be any version).
Before advertising this all, I'd like to:
1) get your feedback; in JBossWS we've always had something similar,
actually making use of established profiles (-PwidlflyXYZ) which is more
complex and rigid. Here I'd stay with a simple server.version property
that can be anything till we have a good reason for having better
control on the mechanism. WDYT?
2) make it clear that atm we only have clean testsuite runs with default
value (no server.version or server.version = 10.0.0.Final). Running
against 10.1.0.CR1 fails because of a wildfly creaper issue (we need a
release & upgrade of it), running against 9.0.2.Final results in a bunch
of failures and errors. Clearly, we should work on resolving all the
failures, I'd say at least when running against the latest 3 released
target containers. In the long term, we'd have 3 jobs on Jenkins/TC and
perhaps even 3 tasks performed by Travis for each PR.
So, for 2) any help is welcome. If you want to run current master
against WildFly 9.0.2.Final, the command to be used is:
mvn -Dserver.version=9.0.2.Final
-Dorg.jboss.resteasy.client.useOldHTTPClient=true install
The reason for the -Dorg.jboss.resteasy.client.useOldHTTPClient=true is
in the upgrade to the new Apache HTTP client api (not available on
9.0.2.Final and older containers). I do plan to try an automatic version
discovery mechanism in the next future so that we (and the final users)
do not have to bother about that.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss