[dan.j.allen]

That's a good question Jakub, one that we hadn't yet explored.

For POST and PUT, I would imagine that it would rely on some sort of data provider (sort of like Arquillian Ape) and verify that the endpoint consumes them properly.

Obviously, taking a declarative approach is going to be very constrained. That's why I think it works best for boilerplate, data-driven tests that make you feel like you are typing unnecessary code. It's a bit like FitNesse or Spock's data tables for testing various values. (There's also the use case of creating a very simple smoke test for a REST service).

[jmnarloch]

For POST and PUT, I would imagine that it would rely on some sort of data provider (sort of like Arquillian Ape) and verify that the endpoint consumes them properly.

Obviously, taking a declarative approach is going to be very constrained. That's why I think it works best for boilerplate, data-driven tests that make you feel like you are typing unnecessary code. It's a bit like FitNesse or Spock's data tables for testing various values. (There's also the use case of creating a very simple smoke test for a REST service).

I really like this idea. Reducing the pain of setting up the test.

We could have REST extension kept seperatly from the Warp and with some smart extendable design we could integrate them together. From the client side it does not make much difference, since the only thing that needs to be configured is the service URL address. And with alternative Warp syntax (@Verify) we could have a declarative aproach here as well. I think that this have some great potential.

[dan.j.allen]

Jakub, you nailed it!

[jmnarloch]

One major update on this topic.

I had finally manage to finish the Jersey proof of concept. https://github.com/jmnarloch/arquillian-extension-warp-rest

Now moving to CXF.

[lfryc]

Great job, Jakub!

What about proposing REST hack-idea for JHackFest [1] this weekend?

We could connect Brno with you through hangout!

[1] http://lukas.fryc.eu/blog/2013/02/jhackfest.html

[jmnarloch]

Lukáš Fryč wrote:

What about proposing REST hack-idea for JHackFest [1] this weekend?

We could connect Brno with you through hangout!

[1] http://lukas.fryc.eu/blog/2013/02/jhackfest.html

Cool!

I can definetly be online.

[jmnarloch]

Finally!

I have prototyped the third and final CXF implementation and by ocassion I have found a bug (https://issues.jboss.org/browse/ARQ-1320) in Warp that at the moment doesn't allow to use the CXF together with Warp, but it can be quickly fixed.

Now. I will wrapp up the code, prepare the tests and we can be ready with the Alpha 1 pretty soon.

[jmnarloch]

By now all the integration test in the Warp REST extension are passing. At the moment I'm writting unit tests for the impl modules, likely it will be done within next couple days. Question is where do we move the code? Into the arquillian-extension-warp? Or do we create completly new one and we make Warp REST extension a first class extension with it's own release cycle?

[lfryc]

Jakub, we could simply move REST extension here

https://github.com/arquillian/arquillian-extension-warp/tree/master/extension

that was the original intention.

however the another live idea is creating framework-specific Arquillian extensions, e.g.:

• Java EE + JSF
• Java EE + REST
• Spring MVC

---

+1 to moving REST to Warp, since the standard Java EE technologies belongs now to core modules (even though the REST extension is REST-provider specific).

[jmnarloch]

We have finnally a pull request opened for this issue

[aslak]

We could put this in the arquillian-extension-rest. What's there now is just an early prototype with very little movement.

We could 'move' the master branch to a branch, replace master with warp-rest, then retro fit the old master branch if needed.

[lfryc]

+1 agree

Aslak Knutsen wrote:

We could put this in the arquillian-extension-rest. What's there now is just an early prototype with very little movement.

We could 'move' the master branch to a branch, replace master with warp-rest, then retro fit the old master branch if needed.