@joelittlejohn@unkish this PR is still just a test demo, but we could put something like this into the project. For now, please keep any feedback to issues with viability. I have cut a ton of corners (added builder generator, using Commons Lang Tuples, etc.). We can change those thing later. The purpose, for now, is just to get something concrete to react to.

I am thinking we can turn this into a wrapper around the SchemaStore, so that the rest of the project doesn't need to understand this change. We could flip this feature on and off by installing an identity transform, instead of a transform that expands properties, so it could live in the project for a while as an experimental feature.

This would change the behavior of the project a little, since document loading would move to the transform, instead of when a rule encountered a$ref, but we could probably hide that detail from the rule implementations.

I have been working on a set of transforms that we can use to handleallOf,anyOf,oneOf andnot as a transform that is applied before the existing rules and I have identified a case where this will definitely not work. Consider a schema where a field can be both either adate and adate-time string:

{  "type": "object",    "anyOf": [      { "properties": { "temporal": { "type": "string", "format": "date" } } }      { "properties": { "temporal": { "type": "string", "format": "date-time" } } }    ]  }

There is no good way to erase thisanyOf and have the rest of the rules work, since this project usesformat to determine the type of the field for a given property. I think the best we could do here is:

{  "type": "object",  "properties": {    "temporal": {      "type": "string",      "anyOf": [ { "format": "date" }, { "format": "date-time" } ]     }   },  "anyOf": [    { "properties": { "temporal": { "type": "string", "format": "date" } } }    { "properties": { "temporal": { "type": "string", "format": "date-time" } } }  ]}

This would result in a Java object being generated with aString field. Conversion to theDate orDateTime would be left to the user.

Personally, if a bunch of time is going to be invested into getting these keywords to work, I would like it to make my life extremely easy when using the project's output. I think that would include creating a set ofJsonSerialziers andJsonDeserializers for situations like these and generate fields of the closest super type or interface of all the alternatives. Even better would be generating some kind of wrapper type that represents the alternative types, like aBiAlternative<Date, DateTime> where the type mapping is all handled in generated code.

I am going to get the code I have cleaned up and pushed. Then I am going to open a competing draft where these keywords are implemented in the existing rules. My gut is telling me that getting an easy implementation of these rules will require adding some kind of extra model that is a little closer to the Java we are trying to generate, but not as concrete as CodeModel.

I pushed some transform examples and an example of a TransformingSchemaStore. Since it appears that inlining$refs will not work, doing multiple passes of transformation is most likely not needed and this code could be simplified. I am not a huge fan of this approach, so I am going to leave this for now and look into supporting this in the rules.