You can use jsonschema2pojo as a Maven plugin, an Ant task, a command line utility, a Gradle plugin or embedded within your own Java app. The Getting Started guide will show you how.
The following message is printed if using the plugin with Gradle 6.0.1:
Property 'configuration' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.
@JsonInclude(JsonInclude.Include.NON_NULL)
@Generated("org.jsonschema2pojo")
@JsonPropertyOrder({
"carId",
"features"
})
public class Testar3 {
/**
* Unique Id for the car
*
*/
@JsonProperty("carId")
private String carId;
/**
* Features for the car
*
*/
@JsonProperty("features")
private List<Object> features = new ArrayList<Object>();
private Map<String, Object> additionalProperties = new HashMap<String, Object>();
/**
* Unique Id for the car
*
*/
@JsonProperty("carId")
public String getCarId() {
return carId;
}
/**
* Unique Id for the car
*
*/
@JsonProperty("carId")
public void setCarId(String carId) {
this.carId = carId;
}
public Testar3 withCarId(String carId) {
this.carId = carId;
return this;
}
/**
* Features for the car
*
*/
@JsonProperty("features")
public List<Object> getFeatures() {
return features;
}
/**
* Features for the car
*
*/
@JsonProperty("features")
public void setFeatures(List<Object> features) {
this.features = features;
}
public Testar3 withFeatures(List<Object> features) {
this.features = features;
return this;
}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
@Override
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);
}
@Override
public boolean equals(Object other) {
return EqualsBuilder.reflectionEquals(this, other);
}
@JsonAnyGetter
public Map<String, Object> getAdditionalProperties() {
return this.additionalProperties;
}
@JsonAnySetter
public void setAdditionalProperty(String name, Object value) {
this.additionalProperties.put(name, value);
}
Hi,
It seems current logic only handles "properties" array to generate POJOs. Is there any programmatic way to extend this logic to additionally support link-relationships representation in POJOs?
Specifically, jersey-server-linking defines @Ref/@Binding annotations that allows to specify resource and template parameter binding.
Sample that comes with the library is a representation bean (POJO) as follows:
... generates same POJO as following schema (without links):
{
"type":"object",
"properties": {
"foo": {
"type": "string"
},
"bar": {
"type": "integer"
},
"baz": {
"type": "boolean"
}
}
}
And since POJO generation is dynamic, I would like to be able to either decorate the generated POJOS dynamically, or to influence the code generating the classes in the first place, to add additional annotations in the generated code.
Beside the obvious decoupling from Jersey, do you see why links are not generated (at all) in the POJOs? Should I specifically add a bag of properties to have the defined links listed?
Thanks for your help.
Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=86
I have a json-schema valid schema (validated using JSV) and I setup my maven project to generate POJO out of it.
I get the following error:
Execution default of goal com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.3.4:generate failed: URI scheme is not "file" (com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.3.4:generate:default:generate-sources)
Using 0.3.4 version.
My schema ref$ to another schema, which is in same src/main/resources/schema directory. I refer to it e.g. "$ref": "./myotherschema.json#"
What am I doing wrong?
Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=87
When I run the generator if there is a .DS_Store file in the json schema directory the build will fail. Wondering if this is by design or if this is a bug.
We have noticed that when running the code generation on Windows and Linux we can inconsistencies of which packages included sub-classes were being created. Given the source files:
And on Windows it generates:
target/generated-sources/virtualization-capabilities-api/com/dell/cpsd/vcenter/capabilities/api/includes/MessageProperties.javatarget/generated-sources/virtualization-capabilities-api/com/dell/cpsd/vcenter/capabilities/api/includes/VirtualMachineQuery.javatarget/generated-sources/virtualization-capabilities-api/com/dell/cpsd/vcenter/capabilities/api/VMQueryRequestMessage.java
We're submitting this new configuration option to ensure that within a directory, files are processed first before any sub-directories to ensure consistency between environments. The default false maintains the existing behaviour to ensure backward compatibility.
We could only provide an integration test for when the option is set to true, as in this case we can verify the behaviour, the false configuration option assertions would depend on the underlying OS.
Below is an example with four coordinates for an image transform. If the point does not include a javaName then the class is called TopLeft. To fix this the name is defined, but that leads to the get/set methods of topLeft, topRight, etc. to be called getPoint and setPoint. The fields are properly named, but the duplicate method names results in invalid Java code. Interestingly the fluent methods (withX) are properly named.
/**
*
* Corresponds to the "topLeft" property.
*
* @return
* The point
*/
@JsonProperty("topLeft")
public Point getPoint() {
return topLeft;
}
/**
*
* Corresponds to the "topLeft" property.
*
* @param point
* The topLeft
*/
@JsonProperty("topLeft")
public void setPoint(Point topLeft) {
this.topLeft = topLeft;
}
public PerspectiveTransform withTopLeft(Point topLeft) {
this.topLeft = topLeft;
return this;
}
/**
*
* Corresponds to the "topRight" property.
*
* @return
* The point
*/
@JsonProperty("topRight")
public Point getPoint() {
return topRight;
}
/**
*
* Corresponds to the "topRight" property.
*
* @param point
* The topRight
*/
@JsonProperty("topRight")
public void setPoint(Point topRight) {
this.topRight = topRight;
}
public PerspectiveTransform withTopRight(Point topRight) {
this.topRight = topRight;
return this;
}
Jackson 2 has a @JsonTypeInfo annotation available so that (de)serialization of classes that extend abstract classes works correctly.
Adding this annotation to an abstract POJO will (during serialization) add a top-level property to the schema that specifies a fully qualified class name that specifies the type that a particular json object should be deserialized to.
This PR allows for an "abstractJavaTypeProperty" that specifies the name of the property that will contain the fully qualified name in the serialized object.
For example, if your schema contains node with:
"abstractJavaTypeProperty" : "className"
The generated POJO will be an abstract class, and will have this annotation:
@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.PROPERTY, property = "className")
Create a schema, e.g. a type with some enum values
Generate POJO
Modify schema, eg. add new value to enum
Re-Generate POJO
What is the expected output?
The Java source now contains the new enum value.
What do you see instead?
The Java source, generated in step 2, remains unchanged.
What version of the tool are you using? On what Java version? (On whatversion of Maven/Ant if applicable?)
Use maven and latest build 0.3.5
If I remove the Java files before step 3, then the Java file is properly generated with the new enum value.
Would it be possible to include a "clean" option to the generate target so that if set to true, all files already present in the generation folder specified would be deleted before starting the generation process (equivalent of deleting manually the already generated files). This is especially important, since you typically do not check-in generate sources, and as such, you expect no sources to be already generated (note that you may have .class reused if found in your class-path, e.g. a jar). Cleaning up source folder before the source generation process therefore makes sense.
I don't know what causes the class not to be refreshed when schema change. Is there any logic that says if the Java (not class) file is present do not regenerate? If the algo (which I believe is the one used) is "if class file exists, do not generate/overwrite source", then I would need to somehow clean not the Java source files but actually the Java (generated) class files from the folder the (maven) project use to store compiled classes, following Java source generation.
Let me know if the description is unclear. I tried my best.
Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=92
Allow to specify jsr310 classes i.e. java.time.* (jdk 8)
but mantain compatibility at compile level 1.6 as previous.
Updated also cli, maven, and ant but not gradle
When using both includeJsr303Annotations and includeGeneratedAnnotation, it seems one still gets javax.annotation.(processing.)Generated instead of jakarta.annotaiton.Generated.
I'm trying to use this tool to generate classes for the OASIS STIX 2.1 schema. This uses allOf everywhere in the schema definitions. Is this something that can be easily achieved?
this plugin won't be compatible to gradle 8.0, as the following error occurs when syncing my project with the plugin enabled:
IncrementalTaskInputs has been deprecated. This is scheduled to be removed in Gradle 8.0. On method 'GenerateJsonSchemaAndroidTask.generate' use 'org.gradle.work.InputChanges' instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#incremental_task_inputs_deprecation
Could this plugin be updated please to conform to these changes?
Should any additional information be required, I'd be happy to help
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
dependenciesjava
opened by dependabot[bot] 0
Releases(jsonschema2pojo-1.1.2)
jsonschema2pojo-1.1.2(May 3, 2022)
Use LinkedHashMap for additional properties, so the original ordering in the JSON is preserved (#1397)
Collection fields are unnecessarily initialized to "null" (#1346)
Enum not getting generated correctly with CamelCase values (#1310)
Support using JSR-303 annotations from 'jakarta.validation' package (#1280)
Item type for array property 'listFta' is incorrectly named ListFtum (#1275)
A universal types-preserving Java serialization library that can convert arbitrary Java Objects into JSON and back, with a transparent support of any kind of self-references and with a full Java 9 compatibility.
?? 零代码、热更新、全自动 ORM 库,后端接口和文档零代码,前端(客户端) 定制返回 JSON 的数据和结构。 ?? A JSON Transmission Protocol and an ORM Library for automatically providing APIs and Docs.