I have a use case where I'm generating schema files from a Java module, of which many of the classes share common property types. Instead of generating a massive schema file for each root class with a list of definitions sub-schemas, I want to be able to generate each type to its own file and reference these types.
For this to work, I'd expect that the generator could either be provided a $id for each type via an annotation (or infer it based on the class name), then use this value in $ref. The generator config itself could be given a root id path as well to prepend to the ids for each class type.
Thinking something like so:
@JsonSchemaId("person")
class Person {
String name;
}
@JsonSchemaId("car")
class Car {
Person driver;
Person passenger;
}
Would then generate two files, one for Person and another for Car.
This behavior would then be enabled (to support backwards compatibility), via the config (with a better name):
var config = JsonSchemaConfig.nullableJsonSchemaDraft4();
config.createMultipleFiles(true);
Given that generateJsonSchema produces a JsonNode, with this particular flag enabled it would not include definitions, and would expect that other schema files that it needs for a fully valid schema would be generated separately (with subsequent calls to the same method, but with a different Class or JavaType).
I have a use case where I'm generating schema files from a Java module, of which many of the classes share common property types. Instead of generating a massive schema file for each root class with a list of
definitions
sub-schemas, I want to be able to generate each type to its own file and reference these types.For this to work, I'd expect that the generator could either be provided a
$id
for each type via an annotation (or infer it based on the class name), then use this value in$ref
. The generator config itself could be given a root id path as well to prepend to the ids for each class type.Thinking something like so:
Would then generate two files, one for
Person
and another forCar
.This behavior would then be enabled (to support backwards compatibility), via the config (with a better name):
Given that
generateJsonSchema
produces aJsonNode
, with this particular flag enabled it would not include definitions, and would expect that other schema files that it needs for a fully valid schema would be generated separately (with subsequent calls to the same method, but with a differentClass
orJavaType
).