On Jun 1, 2016, at 9:14 AM, Ron Sigal <rsigal(a)redhat.com&gt; wrote: Hi guys, After slogging through as many bug JIRAs as possible for 3.0.17.Final, I felt like I needed to do something different for a while, so I started looking at non-blocking IO for JAX-RS 2.1. One of the issues I ran into is the servlet version problem. Even though resteasy-jaxrs declares a dependency on servlet 3.1, its dependency on tjws brings in servlet 2.5, which gets in the way of using servlet 3.1. I've done some refactoring: 1) moved everything related to tjws from resteasy-jaxrs to tjws

2) moved all tests (except i18n tests) from resteasy-jaxrs to resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws)

3) removed the dependency of resteasy-jaxrs on tjws

4) created a dependency of tjws on resteasy-jaxrs

I thought I'd ask for comments before I create a pull request. Two points come to mind: 1) Originally, resteasy-jaxrs-testsuite was created to hold tests specifically related to JAX-RS 2.0 (hence the nextgen packages). The plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff like the new client framework, but it never happened. This might be a good time to do that.

2) I know we've talked about what to do with tjws, but I don't know if we reached a conclusion. This would be a good time to deprecate it, if we're going to do that.

-Ron -- My company's smarter than your company (unless you work for Red Hat) _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

On Jun 1, 2016, at 4:09 PM, Marek Kopecky <mkopecky(a)redhat.com&gt; wrote: On 06/01/2016 06:26 AM, Weinan Li wrote: >> > >> 2) I know we've talked about what to do with tjws, but I don't know if we reached a conclusion. This would be a good time to deprecate it, if we're going to do that. >> > +1 to deprecate it and migrate our tests still using the tjws fully to RESTEasy's cool undertow container :-) > > > > Conclusion here on resteasy-dev list was, that we will use WildFly (not Undertow container). See this mail from Alessio: http://lists.jboss.org/pipermail/resteasy-dev/2016-May/000008.html

We can move QE-internal-RESTEasy-TS to RESTEasy, see http://lists.jboss.org/pipermail/resteasy-dev/2016-May/000016.html • This TS contains all migrated tests from RESTEasy. These tests run against WildFly. _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

By using undertow for one part of tests, we also gain benefit that we could keep improving our resteasy-undertow adapter. Currently we have three main adapters: - undertow adapter - netty adapter - sun jdk adapter The undertow adapter is fully covered by JBoss community. Considering the current popularity of JBoss Swarm, I feel that these lightweight and modular solution will be more and more popular. (Just some personal views)

Il 01/06/2016 13:24, Tomaž Cerar ha scritto: On Wed, Jun 1, 2016 at 1:08 PM, Weinan Li < weli(a)redhat.com > wrote: By using undertow for one part of tests, we also gain benefit that we could keep improving our resteasy-undertow adapter. Currently we have three main adapters: - undertow adapter - netty adapter - sun jdk adapter The undertow adapter is fully covered by JBoss community. Considering the current popularity of JBoss Swarm, I feel that these lightweight and modular solution will be more and more popular. (Just some personal views) Integration tests should be done by arquillian in general, if that means we can by changing the config test on other servers beyond WildFly (servlet) than that is best way to go. Yes, that's basically what I have in mind. Arquillian, and by default wildfly. Then you could configure the tests to run using different containers (it would eventually be just a matter of defining a proper test matrix).

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

> > ARQ + Undertow know each other:http://arquillian.org/modules/undertow-embedded-container-adapter/ My first inclination, like Weinan's, was to think that running everything in Wildfly was pretty heavy, but if we just start Wildfly once, that's not so bad.

After all, that's what the TCK does, as well as the new qe TS.

One problem I still have is that, when I'm working on a problem, I MUCH prefer running tests in an embedded container like tjws or Undertow.

I guess I could just write a standalone test and then turn it into an arquillian test when I'm done. But if Arquillian works with Undertow, which I didn't know, that might be the best of all worlds.

I'm a little worried though about the time it takes Arquillian to create a WAR, which isn't insignificant ...

On 06/01/2016 05:20 PM, Alessio Soldano wrote:

> Il 01/06/2016 20:16, Ron Sigal ha scritto:

> > > ARQ + Undertow know each other: > > > http://arquillian.org/modules/undertow-embedded-container-adapter/ > > >

> > My first inclination, like Weinan's, was to think that running everything > > in > > Wildfly was pretty heavy, but if we just start Wildfly once, that's not > > so > > bad. > > Right, that's what I meant saying that it depends on how you implement the > solution. In practice, we might end up needing more than just a single WFLY > instance (perhaps because we need different container configurations for > different types of tests), but the number of instances should really be > limited (let's say less than 5?).

> > After all, that's what the TCK does, as well as the new qe TS. > > And the JBossWS testsuite ;)

> > One problem I still have is that, when I'm working on a problem, I MUCH > > prefer running tests in an embedded container like tjws or Undertow. > > Not sure what the preference is based on, but if that's because you don't > want to manually start the container, etc... Arquillian does that for you.

I just like the instantaneous startup. For example, I just ran a test in RESTEASY-TEST-WF8, and it took 2.7 seconds to start up Wildfly and another 2.7 seconds to create and deploy the WAR. Better than AS 5 ;-) but still a little annoying.

> > I guess I could just write a standalone test and then turn it into an > > arquillian test when I'm done. But if Arquillian works with Undertow, > > which > > I didn't know, that might be the best of all worlds. > > I've never tried this, but afaiu yes it works with Undertow.

> > I'm a little worried though about the time it takes Arquillian to create > > a > > WAR, which isn't insignificant ... >

> It's not that bad after all; btw, once you have all tests as arquillian > ones > and you ensure they do not make assumptions on the server being there just > for each of them (which is also good), you can most likely make the > testsuite execution concurrent and run multiple tests at the same time.

> 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

-- My company's smarter than your company (unless you work for Red Hat)

_______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

Rostislav Svoboda Principal JBoss QA Engineer ------------------------------------------------------------------------ On 06/01/2016 05:20 PM, Alessio Soldano wrote: Il 01/06/2016 20:16, Ron Sigal ha scritto: ARQ + Undertow know each other:http://arquillian.org/modules/undertow-embedded-container-adapter/ My first inclination, like Weinan's, was to think that running everything in Wildfly was pretty heavy, but if we just start Wildfly once, that's not so bad. Right, that's what I meant saying that it depends on how you implement the solution. In practice, we might end up needing more than just a single WFLY instance (perhaps because we need different container configurations for different types of tests), but the number of instances should really be limited (let's say less than 5?). After all, that's what the TCK does, as well as the new qe TS. And the JBossWS testsuite ;) One problem I still have is that, when I'm working on a problem, I MUCH prefer running tests in an embedded container like tjws or Undertow. Not sure what the preference is based on, but if that's because you don't want to manually start the container, etc... Arquillian does that for you. I just like the instantaneous startup. For example, I just ran a test in RESTEASY-TEST-WF8, and it took 2.7 seconds to start up Wildfly and another 2.7 seconds to create and deploy the WAR. Better than AS 5 ;-) but still a little annoying. If you do TS properly you need to start WF just once so I don't see this as a problem. Starting WF for each test is bad practice.

R. I guess I could just write a standalone test and then turn it into an arquillian test when I'm done. But if Arquillian works with Undertow, which I didn't know, that might be the best of all worlds. I've never tried this, but afaiu yes it works with Undertow. I'm a little worried though about the time it takes Arquillian to create a WAR, which isn't insignificant ... It's not that bad after all; btw, once you have all tests as arquillian ones and you ensure they do not make assumptions on the server being there just for each of them (which is also good), you can most likely make the testsuite execution concurrent and run multiple tests at the same time. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss _______________________________________________ resteasy-dev mailing list resteasy-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/resteasy-dev -- My company's smarter than your company (unless you work for Red Hat) _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on project resteasy-build-tools: groups/excludedGroups require TestNG or JUnit48+ on project test classpath -> [Help 1] What am I doing wrong?

> [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test) on > project resteasy-build-tools: groups/excludedGroups require TestNG or > JUnit48+ on project test classpath -> [Help 1] > > What am I doing wrong? > What version of maven do you use ? Rostislav

>> Conclusion here on resteasy-dev list was, that we will use WildFly (not Undertow container). See this mail from Alessio: http://lists.jboss.org/pipermail/resteasy-dev/2016-May/000008.html > I still feel that using wildfly for *all* the tests is overkill (anyway wildfly is using undertow). By using undertow for one part of tests, we also gain benefit that we could keep improving our resteasy-undertow adapter. Currently we have three main adapters: - undertow adapter - netty adapter - sun jdk adapter The undertow adapter is fully covered by JBoss community. Considering the current popularity of JBoss Swarm, I feel that these lightweight and modular solution will be more and more popular.

Hi guys, After slogging through as many bug JIRAs as possible for 3.0.17.Final, I felt like I needed to do something different for a while, so I started looking at non-blocking IO for JAX-RS 2.1. One of the issues I ran into is the servlet version problem. Even though resteasy-jaxrs declares a dependency on servlet 3.1, its dependency on tjws brings in servlet 2.5, which gets in the way of using servlet 3.1. I've done some refactoring: 1) moved everything related to tjws from resteasy-jaxrs to tjws 2) moved all tests (except i18n tests) from resteasy-jaxrs to resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) 3) removed the dependency of resteasy-jaxrs on tjws 4) created a dependency of tjws on resteasy-jaxrs I thought I'd ask for comments before I create a pull request. Two points come to mind: 1) Originally, resteasy-jaxrs-testsuite was created to hold tests specifically related to JAX-RS 2.0 (hence the nextgen packages). The plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff like the new client framework, but it never happened. This might be a good time to do that.

2) I know we've talked about what to do with tjws, but I don't know if we reached a conclusion. This would be a good time to deprecate it, if we're going to do that.

On 06/01/2016 04:16 AM, Alessio Soldano wrote: > Il 01/06/2016 03:14, Ron Sigal ha scritto: >> >> Hi guys, >> >> After slogging through as many bug JIRAs as possible for >> 3.0.17.Final, I felt like I needed to do something different for a >> while, so I started looking at non-blocking IO for JAX-RS 2.1. One >> of the issues I ran into is the servlet version problem. Even though >> resteasy-jaxrs declares a dependency on servlet 3.1, its dependency >> on tjws brings in servlet 2.5, which gets in the way of using >> servlet 3.1. I've done some refactoring: >> >> 1) moved everything related to tjws from resteasy-jaxrs to tjws >> >> 2) moved all tests (except i18n tests) from resteasy-jaxrs to >> resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) >> >> 3) removed the dependency of resteasy-jaxrs on tjws >> >> 4) created a dependency of tjws on resteasy-jaxrs >> >> I thought I'd ask for comments before I create a pull request. Two >> points come to mind: >> >> 1) Originally, resteasy-jaxrs-testsuite was created to hold tests >> specifically related to JAX-RS 2.0 (hence the nextgen packages). The >> plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff >> like the new client framework, but it never happened. This might be >> a good time to do that. >> > +1, we should try to get rid of all those warnings about old client > stuff in the build. And given we're working on a new minor and that > stuff was deprecated in 3.0.x, we could actually think about removing > the old client framework. Given that we have some large pieces pieces ready to deprecate (old client framework, TJWS, old validation (see my previous note on mailing list), maybe we should do a 3.0.18.Final release in which all this stuff is deprecated so that we can start 3.1.0.Final with a clean slate. Just a thought.

> > >> 2) I know we've talked about what to do with tjws, but I don't know >> if we reached a conclusion. This would be a good time to deprecate >> it, if we're going to do that. >> > +1, sure. > > I'd be glad to review your PR on this. It should be the first step to > revisiting the testsuite to default to using WFLY as container. I created RESTEASY-1410 "Segregate TJWS from resteasy-jaxrs" and PR https://github.com/resteasy/Resteasy/pull/821. Since you agree that we should deprecate TJWS, I'll do one more commit in which all of the TJWS classes are @deprecated.

On 06/01/2016 04:56 PM, Alessio Soldano wrote: > Il 01/06/2016 19:27, Ron Sigal ha scritto: >> >> On 06/01/2016 04:16 AM, Alessio Soldano wrote: >> >>> Il 01/06/2016 03:14, Ron Sigal ha scritto: >>>> >>>> Hi guys, >>>> >>>> After slogging through as many bug JIRAs as possible for >>>> 3.0.17.Final, I felt like I needed to do something different for a >>>> while, so I started looking at non-blocking IO for JAX-RS 2.1. One >>>> of the issues I ran into is the servlet version problem. Even >>>> though resteasy-jaxrs declares a dependency on servlet 3.1, its >>>> dependency on tjws brings in servlet 2.5, which gets in the way of >>>> using servlet 3.1. I've done some refactoring: >>>> >>>> 1) moved everything related to tjws from resteasy-jaxrs to tjws >>>> >>>> 2) moved all tests (except i18n tests) from resteasy-jaxrs to >>>> resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) >>>> >>>> 3) removed the dependency of resteasy-jaxrs on tjws >>>> >>>> 4) created a dependency of tjws on resteasy-jaxrs >>>> >>>> I thought I'd ask for comments before I create a pull request. Two >>>> points come to mind: >>>> >>>> 1) Originally, resteasy-jaxrs-testsuite was created to hold tests >>>> specifically related to JAX-RS 2.0 (hence the nextgen packages). >>>> The plan was to upgrade all of the old tests to use JAX-RS 2.0 >>>> stuff like the new client framework, but it never happened. This >>>> might be a good time to do that. >>>> >>> +1, we should try to get rid of all those warnings about old client >>> stuff in the build. And given we're working on a new minor and that >>> stuff was deprecated in 3.0.x, we could actually think about >>> removing the old client framework. >> >> Given that we have some large pieces pieces ready to deprecate (old >> client framework, TJWS, old validation (see my previous note on >> mailing list), maybe we should do a 3.0.18.Final release in which >> all this stuff is deprecated so that we can start 3.1.0.Final with a >> clean slate. Just a thought. > > Yeah, that would be nice.We should then backport > https://github.com/resteasy/Resteasy/pull/821/commits/db988a936fef4a7c602... > to the 3.0.x branch as well as the commit that will deprecate the old > validation stuff. Perhaps the 3.0.18.Final release should also > include few bug fixes, so we could wait some weeks and see if there's > anything really relevant to be backported there (and better justify > the release) ;-) Ok, cool. I'll update the announcement on Magnolia about 3.0.17.Final being the next to last 3.0.x release, and add a list of deprecated stuff.

>>> >>> >>>> 2) I know we've talked about what to do with tjws, but I don't >>>> know if we reached a conclusion. This would be a good time to >>>> deprecate it, if we're going to do that. >>>> >>> +1, sure. >>> >>> I'd be glad to review your PR on this. It should be the first step >>> to revisiting the testsuite to default to using WFLY as container. >> >> I created RESTEASY-1410 "Segregate TJWS from resteasy-jaxrs" and PR >> https://github.com/resteasy/Resteasy/pull/821. Since you agree that >> we should deprecate TJWS, I'll do one more commit in which all of >> the TJWS classes are @deprecated. > > Cool thanks. > I'm testing the PR on top of current HEAD and merging if everything > is fine (and I think it is) > > 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 -- My company's smarter than your company (unless you work for Red Hat) _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

------------------------------------------------------------------------ Il 01/06/2016 19:27, Ron Sigal ha scritto: On 06/01/2016 04:16 AM, Alessio Soldano wrote: Il 01/06/2016 03:14, Ron Sigal ha scritto: Hi guys, After slogging through as many bug JIRAs as possible for 3.0.17.Final, I felt like I needed to do something different for a while, so I started looking at non-blocking IO for JAX-RS 2.1. One of the issues I ran into is the servlet version problem. Even though resteasy-jaxrs declares a dependency on servlet 3.1, its dependency on tjws brings in servlet 2.5, which gets in the way of using servlet 3.1. I've done some refactoring: 1) moved everything related to tjws from resteasy-jaxrs to tjws 2) moved all tests (except i18n tests) from resteasy-jaxrs to resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) 3) removed the dependency of resteasy-jaxrs on tjws 4) created a dependency of tjws on resteasy-jaxrs I thought I'd ask for comments before I create a pull request. Two points come to mind: 1) Originally, resteasy-jaxrs-testsuite was created to hold tests specifically related to JAX-RS 2.0 (hence the nextgen packages). The plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff like the new client framework, but it never happened. This might be a good time to do that. +1, we should try to get rid of all those warnings about old client stuff in the build. And given we're working on a new minor and that stuff was deprecated in 3.0.x, we could actually think about removing the old client framework. Given that we have some large pieces pieces ready to deprecate (old client framework, TJWS, old validation (see my previous note on mailing list), maybe we should do a 3.0.18.Final release in which all this stuff is deprecated so that we can start 3.1.0.Final with a clean slate. Just a thought. Yeah, that would be nice.We should then backport https://github.com/resteasy/Resteasy/pull/821/commits/db988a936fef4a7c602... to the 3.0.x branch as well as the commit that will deprecate the old validation stuff. Perhaps the 3.0.18.Final release should also include few bug fixes, so we could wait some weeks and see if there's anything really relevant to be backported there (and better justify the release) ;-) Don't forget that EAP 7.0.z will need RESTEasy 3.0.z releases and there are quite strict rules for CP stream to limit scope and prevent regressions. Things which should be fixed must be approved via CP triage and are usually proposed by GSS. So 3.0.18.Final should be release for deprecation of stuff ++ bug fixes requested via EAP 7.0.z CP stream.

Rostislav 2) I know we've talked about what to do with tjws, but I don't know if we reached a conclusion. This would be a good time to deprecate it, if we're going to do that. +1, sure. I'd be glad to review your PR on this. It should be the first step to revisiting the testsuite to default to using WFLY as container. I created RESTEASY-1410 "Segregate TJWS from resteasy-jaxrs" and PR https://github.com/resteasy/Resteasy/pull/821. Since you agree that we should deprecate TJWS, I'll do one more commit in which all of the TJWS classes are @deprecated. Cool thanks. I'm testing the PR on top of current HEAD and merging if everything is fine (and I think it is) 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 _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

-- Weinan Li / JBoss > On Jun 2, 2016, at 1:27 AM, Ron Sigal <rsigal(a)redhat.com&gt; wrote: > > > > On 06/01/2016 04:16 AM, Alessio Soldano wrote: >> Il 01/06/2016 03:14, Ron Sigal ha scritto: >>> Hi guys, >>> >>> After slogging through as many bug JIRAs as possible for 3.0.17.Final, I felt like I needed to do something different for a while, so I started looking at non-blocking IO for JAX-RS 2.1. One of the issues I ran into is the servlet version problem. Even though resteasy-jaxrs declares a dependency on servlet 3.1, its dependency on tjws brings in servlet 2.5, which gets in the way of using servlet 3.1. I've done some refactoring: >>> >>> 1) moved everything related to tjws from resteasy-jaxrs to tjws >>> >>> 2) moved all tests (except i18n tests) from resteasy-jaxrs to resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) >>> 3) removed the dependency of resteasy-jaxrs on tjws >>> 4) created a dependency of tjws on resteasy-jaxrs >>> >>> I thought I'd ask for comments before I create a pull request. Two points come to mind: >>> >>> 1) Originally, resteasy-jaxrs-testsuite was created to hold tests specifically related to JAX-RS 2.0 (hence the nextgen packages). The plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff like the new client framework, but it never happened. This might be a good time to do that. >> +1, we should try to get rid of all those warnings about old client stuff in the build. And given we're working on a new minor and that stuff was deprecated in 3.0.x, we could actually think about removing the old client framework. > Given that we have some large pieces pieces ready to deprecate (old client framework, TJWS, old validation (see my previous note on mailing list), maybe we should do a 3.0.18.Final release in which all this stuff is deprecated so that we can start 3.1.0.Final with a clean slate. Just a thought. Why we don't just do it in 3.1.0 for this big step :-)

>> >>> 2) I know we've talked about what to do with tjws, but I don't know if we reached a conclusion. This would be a good time to deprecate it, if we're going to do that. >>> >> +1, sure. >> >> I'd be glad to review your PR on this. It should be the first step to revisiting the testsuite to default to using WFLY as container. > I created RESTEASY-1410 "Segregate TJWS from resteasy-jaxrs" and PR https://github.com/resteasy/Resteasy/pull/821. Cool! > Since you agree that we should deprecate TJWS, I'll do one more commit in which all of the TJWS classes are @deprecated. It's merged into 'master' branch, so it's for 3.1.0 ;-) >> Thanks >> 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 > -- > My company's smarter than your company (unless you work for Red Hat) > > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev

----- Original Message ----- > From: "Ron Sigal" <rsigal(a)redhat.com&gt; > To: resteasy-dev(a)lists.jboss.org > Sent: Tuesday, May 31, 2016 9:14:22 PM > Subject: [resteasy-dev] tjws > > > > Hi guys, > > After slogging through as many bug JIRAs as possible for 3.0.17.Final, I felt > like I needed to do something different for a while, so I started looking at > non-blocking IO for JAX-RS 2.1. One of the issues I ran into is the servlet > version problem. Even though resteasy-jaxrs declares a dependency on servlet > 3.1, its dependency on tjws brings in servlet 2.5, which gets in the way of > using servlet 3.1. I've done some refactoring: > > 1) moved everything related to tjws from resteasy-jaxrs to tjws > > 2) moved all tests (except i18n tests) from resteasy-jaxrs to > resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws) > > > 3) removed the dependency of resteasy-jaxrs on tjws > > > 4) created a dependency of tjws on resteasy-jaxrs > > I thought I'd ask for comments before I create a pull request. Two points > come to mind: > > 1) Originally, resteasy-jaxrs-testsuite was created to hold tests > specifically related to JAX-RS 2.0 (hence the nextgen packages). The plan > was to upgrade all of the old tests to use JAX-RS 2.0 stuff like the new > client framework, but it never happened. This might be a good time to do > that. > https://issues.jboss.org/browse/RESTEASY-1363 is there to cover upgrading to the new client framework. I'll suspend my work on this until your changes are merged.

> 2) I know we've talked about what to do with tjws, but I don't know if we > reached a conclusion. This would be a good time to deprecate it, if we're > going to do that. > > -Ron > -- > My company's smarter than your company (unless you work for Red Hat) > > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev >