Right. Removing the Raw* classes and the functions that transform from Raw to
non-raw should be the first step.
Once that is done, you can configure the domain classes so they have the same
structure than the expected Json. Looking at the `drives-single.json` used in
expect tests, I think (for example), the Drives class could have something like:
```java
public class Drives {
private List<String> affinities;
@SerializedName("allow_multimount")
private boolean allowMultimount;
private List<License> licenses;
private Map<String, String> meta;
...
}
```
Gson will deserialize the returned JSON into that class. The `@SelectJson`
annotation should be used if you want to deserialize a specific JSON field
instead of starting from the root element (don't know if it is the case).
That is the idea. If you design your classes in a way that match the expected
JSON, then you don't need to add custom response parsers. But that is up to
you. Sometimes you may choose to have a more convenient domain object model and
use some response parsers. Anyway, those Raw* classes seem to be duplicates of
the non-raw ones, and if they could be removed (and the corresponding
functions), that would be nice!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/12#issuecomment-21652477
