Array item type is not named well when array property name ends in 'ies'

[joelittlejohn]

Original author: vishal.c...@gmail.com (October 08, 2012 10:26:33)

What steps will reproduce the problem?
i have a json schema in which schema named bats.jsd is defined to be an array of type bat and i gave a reference to it as follows:
{
"id": "properties",
"description": "A collection of repositories",
"type": "object",
"properties": {
"properties": {
"type": "array",
"items": {
"$ref": "property.jsd"
}
}
}
}

What is the expected output?
my expected output is formation of property.java and properties.java
and properties attribute should be defined as an array of type property.

What do you see instead?
i see proeperty.java, properties.java and propertie.java and the properties in properties.java is defined an array of type property

What version of the product are you using? On what Java version? (On what
version of Maven/Ant if applicable?)
i am using ant task and jsonschema2pojo0.3.2 api for generating pojos.

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=75

[joelittlejohn]

From joelittl...@gmail.com on October 08, 2012 21:57:27
Thanks Vishal. Would you be able to attach all the schemas? It would be useful if I could have you exact set so that I can understand whether this is the expected behaviour or if there's something going wrong here.

This behaviour has definitely caused a lot of confusion in the past and something needs to be fixed. One workaround that you may find useful is to specify the 'javaType' extension attribute in every schema. You can supply a fully-qualified class name as the value, and hence choose the exact class names you want.

[joelittlejohn]

From joelittl...@gmail.com on October 08, 2012 21:58:52
Docs that may be useful:

https://code.google.com/p/jsonschema2pojo/wiki/Reference#javaType

[joelittlejohn]

From vishal.c...@gmail.com on October 09, 2012 05:09:56
Thanks Joe.
But there is a problem with the javatype also.
suppose we have following schemas:

{
"id": "properties",
"description": "A collection of repositories",
"type": "object",
"properties": {
"properties": {
"type": "array",
"items": {
"$ref": "property.jsd"
}
}
}
}

and

{
"id": "property",
"description": "A property",
"type": "object",
"properties": {
"id": {
"type": "integer",
"description": "id associated"
},
"name": {
"type": "string",
"description": "Name of property"
}
}
}
then we might notice that there is formation of propertie.java, properties.java and property.java and the properties attribute in properties.java is defined as an array of propertie.
But it should be an array of property.
If we do it using javatype attribute as you explained then the properties.java will be an array of property.java but property.java is not having the exact attributes according to the schema.
So we have to manually change the import file line in properties.java(pojo) so that the correct file of property.java is imported.
But I have a limitation according to my project that I have to generate the pojos automatically and should not tweak them after they are formed.
So could you please help me in this aspect.

[joelittlejohn]

From joelittl...@gmail.com on October 09, 2012 19:58:16
Vishal, I'm a bit confused as to why you are experiencing this problem. In particular, I would expect that you could solve your problem by applying "javaType" to the schemas.

Would you be able to attach a copy of all the schemas involved so that I can run this with exactly the same input as you? If you don't want to post all of these publicly then feel free to email them to joelittlejohn at gmail.

[joelittlejohn]

From joelittl...@gmail.com on October 09, 2012 20:13:32
I should just mention: I can understand why you are seeing the Propertie.java. jsonschema2pojo is very naive and expects to try to make a singular noun form by removing the 's' from the end of a word. This of course doesn't work for 'properties'

The confusing thing though is that you are seeing an extra type generated. I would not expect this to create redundant types, and I would definitely expect adding 'javaType' to be a successful workaround. This is why I need the exact schemas (if possible) as I'd like to diagnose exactly what's going wrong.

[joelittlejohn]

From vishal.c...@gmail.com on October 12, 2012 05:07:27
Hi Joe.
Thanks a lot for your help so far. But as you asked that you need to see the exact schema that are showing the problems while getting converted to pojos,
I have attached the schemas for you. I did not understood why there is creation of virtualApplianceQuerie.java.
Kindly help me in this aspect.

[joelittlejohn]

From joelittl...@gmail.com on October 12, 2012 13:19:20
So the workaround I suggested (using javaType) appears to work find for me. I simple changed virtualApplianceQuery.jsd to look like:

{
"id": "virtualApplianceQuery",
"description": "A system ",
"type": "object",
"javaType" : "com.ibm.vmcontrol.resources.VirtualApplianceQuery",
"properties": {
"name": {
"type": "string",
"description": "Name of query"
},
"value": {
"type": "string",
"description": "Value of query"
}
}
}

[joelittlejohn]

From vishal.c...@gmail.com on October 13, 2012 05:05:31
Yes Joe, but this is not the problem i am facing.
You can see one more schema which is named as virtualApplianceQueries.jsd which is having an attribute named "virtualApplianceQueries" of type array and the contents of the array should be of type "virtualApplianceQuery".
But the pojo which is getting created is making this attribute to take array of type
"virtualApplianceQuerie".
So this is the actual problem which i am facing

[joelittlejohn]

From joelittl...@gmail.com on October 13, 2012 12:58:51
Vishal, if you modify the schema as I have suggested, you will not see any type generated called 'VirtualApplianceQuerie'. You will see that virtualApplianceQueries is an array of VirtualApplianceQuery, as you require.

[joelittlejohn]

From joelittl...@gmail.com on October 21, 2012 20:21:16
Vishal, hopefully you found the workaround useful. I've made a change in the code to deal with the 'ies' suffix more gracefully. The process of creating a singular name is still very naive but 'ies' is usually the one that people have a problem with so it seems worth having an additional special case for this.

Where a $ref value is concerned, issue#22 remains open to gather the name more nicely from the URL.

[joelittlejohn]

From jrwi5...@gmail.com on November 02, 2012 11:06:07
Perhaps you would be interested in using a library for this:
There is org.sonatype.nexus.util.Inflector which has an (also incomplete) solution.

Here you can see their very simple implementation:
https://github.com/sonatype/nexus/blob/master/nexus/nexus-utils/src/main/java/org/sonatype/nexus/util/Inflector.java

[joelittlejohn]

From joelittl...@gmail.com on November 02, 2012 16:29:25
Thanks John, that could be exactly what I need. I looked at a couple of existing Inflector libraries a while ago, but they all seemed to only allow pluralization, not singularization.

However, I'm reticent to add nexus-utils, plexus-utils and guava (and any other transitive dependencies) for this.

[joelittlejohn]

From joelittl...@gmail.com on March 16, 2013 10:41:52
I noticed that the Inflector used by Sonatype in nexus-utils is actually taken from a DZone code snippet. It has no license attached but I've got express permission from the author to use the code, so I'll add this in 0.3.6.