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
7:27 a.m.
----- Original Message -----
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?
To me server.version seems as good option. I
usually use server.home when running the testsuite.
This touches a bit another thing - I've send PR with README for the testsuite module:
https://github.com/resteasy/Resteasy/pull/894
The PR contains just information about test documentation, but I would like to add there
later information about available properties,
example how to run whole testsuite or single test and how to specify another resteasy
version for client side of the tests (https://github.com/resteasy/Resteasy/pull/898).
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),
I had talk with ladicek - the creaper version we use
currently is 0.9.4.
In version 0.9.5 the change was made that it is not needed to release new creaper with
server version anymore.
He suggest to upgrade to 1.4.0. Which I did in this PR:
https://github.com/resteasy/Resteasy/pull/898
It this was not what you meant, we can still talk to him to release new version.
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
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
11:49 a.m.
Il 15/08/2016 14:27, Katerina Novotna ha scritto:
----- Original Message -----
> 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?
To me server.version seems as good option. I usually use server.home when running the
testsuite.
Good, thanks for the feedback.
This touches a bit another thing - I've send PR with README for the testsuite
module:
https://github.com/resteasy/Resteasy/pull/894
Merged
The PR contains just information about test documentation, but I would like to add there
later information about available properties,
example how to run whole testsuite or single test and how to specify another resteasy
version for client side of the tests (https://github.com/resteasy/Resteasy/pull/898).
Merged this one too. And yes, I also want to eventually write down some
notes on this topic, just wanted to finish up the actual changes first.
If you want to start writing a doc proposal here, feel free and send a
PR, thanks :-)
> 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),
I had talk with ladicek - the creaper version we use currently is 0.9.4.
In version 0.9.5 the change was made that it is not needed to release new creaper with
server version anymore.
He suggest to upgrade to 1.4.0. Which I did in this PR:
https://github.com/resteasy/Resteasy/pull/898
Merged, thanks. I didn't think we
could move to 1.4.
It this was not what you meant, we can still talk to him to release
new version.
As long as the testsuite works fine (and it does), it's ok, thanks
:-)
As a matter of fact, I've just changed the Travis CI to run the
build/testsuite both for each commit/PR, one with against WildFly
10.0.0.Final and one against WildFly 10.1.0.CR1 (will move to final when
available). Cool :-)
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
3054
days inactive
3059
days old
2 comments
2 participants
participants (2)
-
Alessio Soldano -
Katerina Novotna