RepositoryRestConfiguration now allows to configure to return a response body for the deletion of item resources. The controller implementation follows the same patter we have already established for creation and updates: unless explicitly enabled or disabled we now consider the presence of an accept header as indicator of whether a response body should be rendered.
This could be a "breaking" change for clients having explicitly expected 204 until now even for requests with an Accept header. If that's an issue, those should either explicitly disable the setting, do not submit an Accept header or loosen their expectations to expect either 200 or 2xx as indicator of success in general.
Fixes#2225.
Additional cleanups in QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver to make sure a QuerydslRepositoryInvokerAdapter is only applied if the QuerydslPredicateBuilder actually exposes a predicate. Extracted a couple of methods to make sure the mapping pipeline reads nicely.
Upgraded to JSONPath 1.1.0 as 0.9 is not supported with Spring 4.2 anymore. Tweaked integration tests due to changed semantics and internals of JSONPath >= 1.0.
Extracted store specific tests into separate test modules to prevent classpath overlap between projects. Those tests are now executed in an "it" build profile to prevent the tests being packaged for distribution on release.
Use Map-based repositories and mapping contexts for test in the Core and WebMvc module.
Slightly changed the configuration API for lookup types on RepositoryRestConfiguration.
Related ticket: DATAREST-776.
