Add config option to choose commons-lang3 for hashCode/toString implementation

[steowens]

One of the things I found troublesome was the fact that there was no way to have your POJO objects depend on Commons Lang3 versus Commons Lang without changing the import statements post generation.

Another thing I would like to see is the ability to edit the generated code with annotations and have the changes to the schema merged in.

For example if i have a pojo with the field:

@id
@JsonProperty("foo")
String id;

Note the @id field was added manually.

It would be great if post re-generation or update to schema that the manually added annotations were preserved wherever possible.

[joelittlejohn]

Good point about commons-lang. 2.x is getting quite long in the tooth now and I think a configuration property to choose the commons-lang version would be a good addition. I'll add this.

Regarding the annotations, this has actually been raised before (#107) but I have so far not been able to think of a clean way to do this. One way is to indicate in the schema what annotations would be required (e.g. an extension property like javaAnnotations) but one problem is that to accommodate annotation arguments you would end up having to support a lot of Java syntax. I'm trying to envision a solution that could work based on merging source files as you suggest, but this poses a variety of problems in itself.

One option might be for you to attach your annotations to an interface and use the javaInterfaces extension property to force your generated type to implement the interface. As you add properties to the interface, they will be forced to match the schema because they'll be checked at compile time. I think it might just work :) Of course your annotations would have to be applied to methods, not fields.

EDIT: forget that, Java's @Inherited rules won't allow this to work.

[steowens]

I understand the difficulty on finding a clean way to preserve existing annotations. It is not too much of a problem however. At least with the plugin I wrote which puts the generated source in a target directory. On initial generation I just copy the files to the main/java/src directory, and then when I make updates, I just do a compare (in eclipse) between the re-generated file and the actual source file. The eclipse compare makes it easy to merge in the changes. A real bonus however would be the ability to pepper the generated source with javax.validation constraints. Also it is too bad that there is not a standard @description annotation. It would be nice to be able to use @description annotations on all fields and places corresponding to the description attribute in json schema.

[steowens]

One possible auto merging solution might be to leverage reflection during the generation process. If for example you knew you were going to generate a com.foo.bar.Baz class, you might be able to use a java class loader to look for an existing com.foo.bar.Baz class in the classes directory, load it up and use reflection to identify any additional annotations that might exist on the fields methods and properties. You could then include these extra annotations in the generated output. This presumes of course that the maven plugin is being used in something other than a standard build cycle and is being executed at development time. I also like your idea of using an extension property in the json schema itself I could imagine for example a property such as:
"annotations": [
{
"name": "Id"
},
{
"name":"Indexed",
"attributes":[
"key":"unique",
"value":"true",
"type":"boolean"
]
} ,
{
"name":"CompoundIndexes",
"value":{
"type":"array",
"elements":{
"type":"annotation",
"name":"CompoundIndex",
"attributes":[
{
"key":"name",
"value":"age_idx",
"type":"string"
},
{
"key":"def",
"value":"{'lastName': 1, 'age': -1}",
"type":"string"
}
]
}
}
"attributes":[
]
}
]

[joelittlejohn]

I'm going to use this ticket to cover the 'choose commons-lang version' feature. We can pick up the custom-annotations stuff in #107 if necessary. Thanks again for your comments!