Me and Aslak have discussed an option that Warp-like API could be moved into Core itself.
Conceptually, Warp consists from several pieces:
- class transformer (allows to use client-side (anonymous and inner classes) inside the server-side tests)
- command bus (communicates Warp commands between client and server - sort of “remote Arquillian events”)
- request interception (HTTP proxy)
- framework specific extensions (such as JAX-RS or JSF)
- Warp API (Warp.initiate(…).observe(…).inspect(…);
- Warp SPI (lifecycle bindings - @BeforeServlet, @AfterServlet…)
As Aslak realized, HTTP proxy is not required in lot of scenarios. It is basically good fit for situations where multiple requests are potentially candidates to be Warp-ed.
In simple REST-client scenarios, it is a overkill though, since there is only one request in fly at the time.
Since command bus (2) in some form already exists in the Core itself, the only piece that we would have to migrate to Core in order to enable Warp-light (not in a sense like Bud-light) is (1) class transformer and API (5).
Then we could open rich Core SPI that would enable extensions like todays-Warp to come with new ways how to intercept and filter appropriate requests (Warp.observe(filter) part) the same as HTTP proxy (3) do and how anything like servlet-filter can perform as well.
The last final piece are framework specific extensions (4) which can be integrated into framework-specific extensions (TBD).
This would help Warp to find new home while opening space for innovation.