There's a difference between 2.15.0 and 2.15.0.redhat-620102 that is causing the test failures.
After digging a bit I found that the difference is in camel-xstream and more precisely into the AbstractXStreamWrapper class. I copied on gist the source codes of the 2 versions so you can easily compare them.

So this is the original version https://gist.github.com/mariofusco/e404b8e477e833732f02 (the one in camel-xstream 2.15.0 that works). Here unmarhsall gets invoked and on line 251 it does

return getXStream(exchange.getContext().getClassResolver())

There it calls getXStream() and in turn createXStream() passing the ClassResolver. It creates an XStream using the empty constructor (line 84) and by default that empty constructor creates a CompositeClassLoader that is able to find the class (Cheese1 in that test case) of the kproject domain.

Now the 2.15.0.redhat-620102 version https://gist.github.com/mariofusco/5814b873ad0a1af4f4a8
In the same way as before unmarhsall gets invoked but this time (line 278) it does

return getXStream(exchange.getContext()).unmarshal(reader);

So once again getXStream() is called but this time passing a CamelContext instead of a ClassResolver. There (line 87) it does

createXStream(context.getClassResolver(), context.getApplicationContextClassLoader());

so calling an overload of createXStream taking 2 arguments: a ClassResolver and a ClassLoader. Once again it creates an XStream using the no-args constructor (line 107) but immediately after it changes the ClassLoader (line 115) setting the one passed to the createXStream() method. This ClassLoader is now the root sun.misc.AppClassLoader and of course xstream is no longer able to find the class defined in the kproject there.

I don't know how to proceed about this (nor why the productized version of camel-xstream is different by the original one). Feel free to forward this explanation to anybody who could be aware of why this difference has been introduced and let me know what I could do about this.