Add ResourceProcessor support magic from Spring Data REST

[mxsb]

Maybe its a good idea to provide something like ResourceProcessorHandlerMethodReturnValueHandler and ResourceProcessorInvokingHandlerAdapter from Spring Data REST in this project (Or maybe move the classes).
When using Spring HATEOAS such components are very handy. At the moment users have to copy the classes from Spring Data REST when using only Spring HATEOAS.
This can be the first step to provide something like a Spring Boot Autoconfiguration for HATEOAS webapps.

[odrotbohm]

If that was possible easily that class would already live here :). The problem is that it's using the advanced generics resolution implemented in Spring Data Commons' TypeInformation. That module however depends on Spring HATEOAS so that moving RPHMRVH here would create a cyclic dependency between the modules. Bringing TypeInformation over to Spring HATEOAS feels like a bit of a stretch, too.

We might wanna investigate the usage of ResolvableType in RPHMRVH instead of TypeInformation to remove that dependency. However, so far I've always run into limitations of ResolvableType that prevented the usage.

If you already have a copy of the class, you might wanna give it a spin and file a ticket and PR against Spring Data REST to do that refactoring?

[mxsb]

Since we use Spring Data too we have no dependency problem by using TypeInformation.
I checked the topic and it seems like one have to build something like TypeInformation to replace it. ResolvableType seems not ready to do the job. Maybe TypeInformation can be part of the Spring Framework some day?

[odrotbohm]

I gave it a spin in the course of DATAREST-726 and it has sort of worked although it required some quirks. I'd like to release this as a Hopper milestone to see whether we actually break stuff by that move but we could then move the type over to Spring HATEOAS,

[odrotbohm]

That's place now. I filed DATAREST-837 to track the switch to the types now contained here including deprecation etc.