Original author: [email protected] (December 23, 2010 00:34:19)

Problem:

Generating apidocs into the main repo like:

https://jsonschema2pojo.googlecode.com/hg/apidocs/

is generally an annoyance, causing additional noise in changesets and more regular conflicts when merging. The latest dev docs are also (arguably) not that useful.

Solution:

Publish javadocs for releases into the wiki repo as per:
http://littleware.blogspot.com/2009/11/publish-javadoc-to-google-code-via.html

(hopefully in an automated, or at least scripted way :D)

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

Original author: [email protected] (December 16, 2010 13:45:01)

"foo":{
"type":"array",
"items":{"type":"string"}
}

creates:

List<String> foo;

which then needs user-initialisation. I'd prefer:

List<String> foo = new ArrayList<String>();

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

Original author: [email protected] (September 25, 2011 20:35:29)

Add an m2e connector so that jsonschema2pojo can be used with Eclipse Indigo & m2e without build warnings, and so that generated source folders are added to Indigo/m2e projects without any manual project config steps.

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

Original author: [email protected] (February 23, 2011 12:31:19)

Many of the non-structural JSON Schema rules (e.g. minimum/maximum, pattern, minItems/maxItems, etc) can be usefully represented using the JSR-303 annotations.

This should be optional, there needs to be a behavioural property to control this and it should probably be off by default.

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

Original author: [email protected] (April 25, 2012 07:50:49)

java.lang.NullPointerException
at com.googlecode.jsonschema2pojo.maven.Jsonschema2PojoMojo.getPropertyWordDelimiters(Jsonschema2PojoMojo.java:226)
at com.googlecode.jsonschema2pojo.rules.PropertyRule.getPropertyName(PropertyRule.java:153)
at com.googlecode.jsonschema2pojo.rules.PropertyRule.apply(PropertyRule.java:75)
at com.googlecode.jsonschema2pojo.rules.PropertyRule.apply(PropertyRule.java:43)
at com.googlecode.jsonschema2pojo.rules.PropertiesRule.apply(PropertiesRule.java:63)
at com.googlecode.jsonschema2pojo.rules.PropertiesRule.apply(PropertiesRule.java:34)
at com.googlecode.jsonschema2pojo.rules.ObjectRule.apply(ObjectRule.java:110)
at com.googlecode.jsonschema2pojo.rules.ObjectRule.apply(ObjectRule.java:56)
at com.googlecode.jsonschema2pojo.rules.TypeRule.apply(TypeRule.java:96)
at com.googlecode.jsonschema2pojo.rules.TypeRule.apply(TypeRule.java:33)
at com.googlecode.jsonschema2pojo.rules.JsonSchemaRule.apply(JsonSchemaRule.java:74)
at com.googlecode.jsonschema2pojo.rules.JsonSchemaRule.apply(JsonSchemaRule.java:67)
at com.googlecode.jsonschema2pojo.rules.JsonSchemaRule.apply(JsonSchemaRule.java:31)
at com.googlecode.jsonschema2pojo.SchemaMapperImpl.generate(SchemaMapperImpl.java:66)
at com.googlecode.jsonschema2pojo.cli.Jsonschema2Pojo.generate(Jsonschema2Pojo.java:88)
at com.googlecode.jsonschema2pojo.maven.Jsonschema2PojoMojo.execute(Jsonschema2PojoMojo.java:172)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

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

Original author: [email protected] (May 11, 2012 21:56:37)

This task tracks anything related to automated releases.

Tasks other than mvn release include:

• updating references and examples on the wiki
• uploading javadocs, maven plugin docs, ant task docs to the wiki
• bundling various jars into convenient release archives
• uploading archives to google code downloads area

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

Original author: [email protected] (April 28, 2011 19:22:08)

Alongside the maven plugin and cli, it would be good to offer an Ant task to invoke jsonschema2pojo.

Feel free to +1 this ticket by commenting if you're interested in this.

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

Original author: [email protected] (February 07, 2012 13:52:26)

What steps will reproduce the problem?
1.
create the file "metadatum.json" with this content :
{
"description" : "piece of metadata",
"type" : "object",
"properties" : {
"name" : { "type" : "string"},
"value" : { "type" : "string"}
}
}

2.
in the same folder, create the file "metadata.json" with this content :
{
"description" : "group of metadata",
"type" : "object",
"additionalProperties" : {
"type" : "object",
"javaType" : "mypackage.Metadatum",
"$ref" : "metadatum.json"
}
}
3. run the generation with the maven plugin

1. Do this on a second computer, with not exactly the same OS, JDK (and probably maven jars)

What is the expected output?

Two classes : Metadata, Metadatum. Metadata contains a Map<String, Metadatum>

What do you see instead?

on "GoodComputer", always the expected output

on "BadComputer", always Metadata and MetadataProperty (no Metadatum)

Note that the behaviour persists on both computers with or without the line
"javaType" : "mypackage.Metadatum",

What version of the product are you using? On what operating system?

Version 0.1.10 (tried to upgrade to 0.2.1 without more luck)

OS :
GoodComputer : Ubuntu 10.04.3 LTS with SUN JDK 1.6.0_26
BadComputer : Ubuntu 10.04.1 LTS with SUN JDK 1.6.0_22

both have default maven2 (2.2.1) from the ubuntu repos

Something occurred to me while writing this report, I checked it and I think I've found the cause of the problem :
Jsonschema2Pojo.generate uses File.listFiles to loop on files from the input directory.
A quick java test program demonstrated that listFiles (as documented) does not return the files with the same order : metadatum.json comes first on GoodComputer and second on BadComputer.

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

Original author: [email protected] (March 15, 2011 22:27:38)

not a big problem, but maven3 complains about missing plugin versions.

patch included

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

Original author: [email protected] (December 23, 2010 13:29:25)

A the moment jsonschema2pojo doesn't support "$ref" style syntax for referencing other schemas (see http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.28).

Some factors to consider:

• We need to make sure we have support for relative URIs.
• Where a second refs exist to an already referenced schema, we should be reusing the same java type IMO
• The ref mechanism is still under discussion and may change in the next draft (see http://groups.google.com/group/json-schema).

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

Original author: [email protected] (July 27, 2011 16:45:40)

Migrate to git now that it's supported by googlecode.

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

Original author: [email protected] (April 18, 2011 17:24:07)

Below are the two test schemas. Put them into a testSchemas directory, then run
./jsonschema2pojo -s testSchemas/*.json -t testSource

{
"title" : "House",
"id" : "http://testtypes.com/house.json",
"description" : "house type",
"type" : "object",
"properties" : {
"cat" : {
"$ref" : "pet.json"
},
"dog" : {
"$ref" : "pet.json"
}
},
"$schema": "http://json-schema.org/draft-03/schema#"
}

{
"title" : "Pet",
"id" : "http://testtypes.com/pet.json",
"description" : " Pet",
"type" : "object",
"properties" : {
"name" : {
"type" : "string",
"required" : false
},
"age" : {
"type" : "integer",
"minimum" : 1,
"maximum" : 12,
"required" : false
}
},
"required" : true,
"$schema": "http://json-schema.org/draft-03/schema#"
}

What is the expected output?
There should be a Pet class. Getters/setters on the House class should take/return Pet for getDog/getCat/setDog/setCat methods.

What do you see instead?
Instead there is a Cat class, and the setters/getters use the Cat class.

What version of the product are you using? On what operating system?
uing 0.1.7, on RHEL5

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

Original author: [email protected] (April 18, 2012 22:15:06)

jsonschema2pojo requires only that Jackson can serialize the generated types, not that they must be serializable according to java.io.Serializable. This interface should be removed from generated POJOs.

It's possible to create a schema that causes types to generated that have references to java.lang.Object. It's also possible to reference just about any non-serializable class using the javaType property. When this happens, static code analysis tools like findbugs show warnings (since instances can no longer be guaranteed to be serializable).

After this fix, generated POJOs will no longer implement java.io.Serializable.

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

Original author: [email protected] (June 04, 2011 20:58:50)

When invoking jsonschema2pojo via the Maven plugin, the project classpath isn't inherited during the plugin execution.

This means that reusing existing types (as described at http://code.google.com/p/jsonschema2pojo/wiki/Reference#javaType) is difficult because the project dependencies are not visible when the plugin is executed so new types are created.

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

Original author: [email protected] (May 08, 2012 00:12:56)

What steps will reproduce the problem?

1. Use word-delimiters option with a hyphen value from the CLI

What is the expected output?
The name of the generated file.

What do you see instead?
pmarchwiak$ ./jsonschema2pojo -s schema.json -t src/java/ -p com.example --word-delimiters "-"
Exception in thread "main" java.lang.IllegalArgumentException: Can not set [C field com.googlecode.jsonschema2pojo.cli.Arguments.propertyWordDelimiters to java.lang.String
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:657)
at com.beust.jcommander.ParameterDescription.addValue(ParameterDescription.java:211)
at com.beust.jcommander.ParameterDescription.addValue(ParameterDescription.java:159)
at com.beust.jcommander.JCommander.parseValues(JCommander.java:553)
at com.beust.jcommander.JCommander.parse(JCommander.java:246)
at com.beust.jcommander.JCommander.parse(JCommander.java:229)
at com.googlecode.jsonschema2pojo.cli.Arguments.parse(Arguments.java:76)
at com.googlecode.jsonschema2pojo.cli.Jsonschema2Pojo.main(Jsonschema2Pojo.java:58)

What version of the product are you using? On what operating system?

0.2.3
OS X 10.6.8

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

Original author: [email protected] (April 17, 2012 14:15:13)

feature to handle AVRO schema format defined in JSON so that this converter can convert from AVRO schema to POJO.

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

Original author: [email protected] (February 22, 2011 14:36:34)

The "format" schema node can be used along with any value for "type". The spec does recommend that format is only used for primitive types, though this is not enforced.

Need to be able to e.g. specify a utc millisec property like:

{ "type" : "integer", "format" : "utc-millisec"}

rather than just

{ "type" : "string", "format" : "utc-millisec"}

Where the format is not recognised, jsonschema2pojo currently falls back to a java.lang.String, however this should fallback to whatever type applies based on the "type" node.

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

Original author: [email protected] (January 14, 2011 15:38:49)

Create a framework that allows end-to-end acceptance testing of jsonschema2pojo via its maven plugin.

See this clone:
https://matthewgilliard-maven-plugin-testing.googlecode.com/hg/

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

Original author: pavel.finkelshtein (February 24, 2012 21:47:31)

What steps will reproduce the problem?
1.create file torrent.json
with contents
{"build":25053, "props":[
{
"hash":"71D6FC08482AEF2903C5994C4842455D5C97CD63",
"trackers":"http://bt.rutracker.org/ann?uk=11111111\r\n\r\nhttp://retracker.local/announce\r\n\r\nhttp://ix.rutracker.net/ann?uk=111111111\r\n
"ulrate":0,
"dlrate":0,
"superseed":0,
"dht":1,
"pex":1,
"seed_override":0,
"seed_ratio":1500,
"seed_time":0
}
]}

2. try to generate POJO

What is the expected output?
Some POJO

What do you see instead?
Instead I see emty directory "java-gen"

What version of the product are you using? On what operating system?
I'm using jsonschema2pojo-cli-0.2.1.jar
Ubuntu 11.10 x64
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)

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

Original author: [email protected] (June 12, 2011 15:35:52)

Problem:

It you omit the targetPackage parameter for the maven plugin you will receive a NullPointerException when running the generate build.

Affected version(s):

0.1.9.

Workaround:

Include the target package parameter in your plugin configuration like:

<targetPackage>com.example</targetPackage>

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

Original author: [email protected] (April 17, 2012 15:05:45)

The current maven plugin works with the older version(1.6.4) of Jackson, but does not work with the Jackson 2.0, as it has a different package structure. Please update the maven plugin, so that it supports Jackson 2.0.

Thanks.

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

Original author: [email protected] (February 24, 2012 20:57:23)

I want to generate some pojos with 64bit integer (i.e. long) fields. I can't use type=number (java type Double) because of the loss of precision.

Refer to this json schema:

{
"type":"object",
"properties":{
"prop1":{"type":"object", "javaType":"java.lang.Long"},
"prop2":{"type":"object", "javaType":"long"},
"prop3":{"type":"integer", "javaType":"java.lang.Long"},
"prop4":{"type":"integer", "javaType":"long"}
}
}

prop1 works as expected (but is limited to non-primitive).

prop2 works partly. The generated pojo is as expected, but a "long.java" class is also generated that I have to manually delete. This is because jsonschema2pojo uses ClassLoader.loadClass to check for existing classes, but this method doesn't work for primitives. A common way to handle primitive class lookup is to just make your own Map<String,Class> lookup. See http://stackoverflow.com/questions/180097/dynamically-find-the-class-that-represents-a-primitive-java-type

prop3 and prop4 don't work (the pojo has int/Integer) because javaType is only used for type:object. But I wish they would work because my field is really a (64-bit) integer, not an object.

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

Original author: [email protected] (December 28, 2011 21:56:53)

A property to switch off type generation for a maven build would be useful (similar to surefire/failsafe property 'skipTests').

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

Original author: [email protected] (January 19, 2012 07:53:52)

Steps to reproduce:

1. Launch jsonchema2pojo via command line on linux
2. No class def found exception is thrown

Expected:
No exception is thrown.

Fix (update jsonschema2pojo launcher):
java -cp jsonschema2pojo-cli-0.2.0.jar:/lib/jsonschema2pojo-core-0.2.0.jar "$@"

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

Original author: [email protected] (February 22, 2011 15:08:50)

What steps will reproduce the problem?

1. Create a schema that has a property with a special character in the name (i.e. a character that is not allowed in a java identifier name) e.g. my-special-property (special character here is hyphen)
2. Generate Java types for this schema
3. Try marshalling/unmarshalling using Jackson

What is the expected output?
Values for this property should be marshalled/unmarshalled correctly.

What do you see instead?
Java Bean property is 'my_special_property' (getMy_special_property, setMy_special_property) which is good, but marshalling to json produces the wrong property name (my_special_property instead of my-special-property) and unmarshalling from json always treats values as additionalProperties.

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

Original author: [email protected] (June 09, 2011 17:08:48)

If possible, it would be nice if the serialization ordering matched the schema definition. At present there is no such guarantee when serializing POJOs to JSON.

Should be quite straight-forward using the [http://jackson.codehaus.org/1.6.5/javadoc/org/codehaus/jackson/annotate/JsonPropertyOrder.html @JsonPropertyOrder] annotation.

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

Skipping this issue number to maintain synchronization with Google Code issue IDs.

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

Original author: [email protected] (February 22, 2011 15:42:25)

Include support for property defaults. See http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.20.

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

Original author: [email protected] (February 23, 2011 10:31:27)

The idea of union types is potentially quite incompatible with Java so we may end up with a fairly naive implementation here that offers support for union types only in the most basic sense. I'd like to think that jsonschema2pojo could at least avoid messy failure when a union type is encountered.

I have a few ideas for how this could be implemented:

1. On detecting a union type, just take the first type and proceed as normal. This is not fantastically useful (union types would still be avoided when writing schemas for jsonschema2pojo) but at least code generation could continue.
2. On detecting a union type, create some marker interface which all types in the union will implement. This allows relationships between the POJOs to remain rigidly enforced. This can't work for primitive types though, e.g. {"type" : ["integer","string"]}.
3. On detecting a union type, proceed to generate the two or more types specified (if they are complex), but mark any usages of that union type as java.lang.Object. Relationships between the generated POJOs become a bit more difficult to understand, and it becomes quite easy to compose Java objects in a way that will produce invalid JSON.

Both option 2 and 3 would likely need to take advantage of Jackson's polymorphic deserialization features:
http://wiki.fasterxml.com/JacksonPolymorphicDeserialization
http://jira.codehaus.org/browse/JACKSON-91

At the moment, I'm thinking Option 3 is the most sensible/useful.

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

Skipping this issue number to maintain synchronization with Google Code issue IDs.

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

Original author: [email protected] (February 24, 2011 14:23:37)

Need to replace the current, stale copyright notices with a date range (since these source files have changed since creation).

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

Original author: [email protected] (July 09, 2011 15:44:44)

The 'optional' schema rule was removed in draft 03 (replaced by 'required'). The deprecated classes remaining in jsonschema2pojo will be removed in 0.2.0.

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

Original author: [email protected] (May 12, 2012 18:27:51)

http://code.google.com/p/mockito/

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

Original author: [email protected] (July 06, 2011 23:08:55)

We're currently mapping various schema types to primitive types, which doesn't work well when incoming JSON omits a property altogether. Since Java properties with primitive types are obviously not nullable, we end up with implicit defaults, and no way to distinguish between a value that was omitted and a value that was equal to the primitive default value.

Simple example...

for this schema:
{
"type" : "object",
"properties" : {
"a" : {
"type" : "integer"
}
}
}

we end up with a Java property of type 'int', and hence this data:

{ "a" : 0 }

is indistinguishable from this data:

{}

Clearly this is a significant change to the way POJO generation works (a breaking change in some rare cases where auto-boxing is not enough to keep things happy), hence this is targetted for 0.2.0.

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

Original author: MLeoDaalder (May 25, 2012 11:56:50)

What steps will reproduce the problem?
The attached file contains a spurious comma and jackson rightly throws an exception.

What is the expected output?
[ERROR] Failed to execute goal com.googlecode.jsonschema2pojo:jsonschema2pojo-ma
ven-plugin:0.2.4:generate (default) on project basispoort-logic: Execution defau
lt of goal com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.2.4:gen
erate failed: com.fasterxml.jackson.core.JsonParseException: Unexpected characte
r (',' (code 44)): was expecting double-quote to start field name
at [Source: <path_to_file>/ProductDetails; line: 11, column: 21]
-> [Help 1]

What do you see instead?
[ERROR] Failed to execute goal com.googlecode.jsonschema2pojo:jsonschema2pojo-ma
ven-plugin:0.2.4:generate (default) on project basispoort-logic: Execution defau
lt of goal com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.2.4:gen
erate failed: com.fasterxml.jackson.core.JsonParseException: Unexpected characte
r (',' (code 44)): was expecting double-quote to start field name
at [Source: java.io.BufferedInputStream@a8198c; line: 11, column: 21]
-> [Help 1]

What version of the product are you using? On what operating system?
The Maven plugin at version 0.2.4 on Windows XP.

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

Original author: [email protected] (June 09, 2011 20:58:16)

It's typical to use JSON as a minimal/lightweight serialization format. Usually, for the sake of brevity, a good signal/noise ratio, and sematic correctness, properties which don't have a value are omitted rather than present with a null value.

e.g.

{ "id" : "5652963" }

is preferred over

{ "id" : "5652963", "name" : null }

By default, Jackson includes null valued properties in serialized output but this can easily be changed using @JsonSerialize(include=JsonSerialize.Inclusion.NON_NULL).

I believe this annotation should be used by default, my guess is that most JSON users prefer the lighter/cleaner format. If required, I'll add a parameter to allow this to be removed though, for those that want to see the nulls.

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

Original author: [email protected] (December 16, 2010 10:11:43)

It's unnecessarily verbose to create these POJOs.

Thing thing = new Thing();
thing.setName(name);
return thing;

Could we either:

• allow multi-arg constructors:

  return new Thing(name);

• have builder-style setters

  (setters return "this" instead of void-type)

  return new Thing().setName(name);

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

Original author: [email protected] (February 22, 2011 15:40:50)

Now that $ref has been implemented (see issue #7), implementing 'extends' should be fairly simple. Should be possible to target 0.1.7 for this change.

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

Original author: [email protected] (June 05, 2011 17:34:36)

When jsonschema2pojo runs it adds the output directory as a source root so that generated classes are compiled and included in the project artifact. This should really be optional.

We need a new configuration parameter for the maven plugin:

addCompileSourceRoot (default=true)

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

Original author: [email protected] (June 05, 2011 17:59:35)

It would be good if documentation for the the Maven plugin goals was generated and published on the site somewhere. At the moment the wiki contains enough info to get started, but as the number of plugin parameters grows some more complete docs will be required.

We don't need to whole output from mvn site, just the docs for the generate goal. The Maven plugin plugin should do the job.

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

Original author: [email protected] (December 22, 2010 16:42:22)

In case we don't know in advance what all the properties will be, we would still like to be able to marshall and unmarshall into Java easily.

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

Original author: [email protected] (March 20, 2011 22:56:03)

At the moment, most values of the 'format' rule result in a String type Java property. When using the POJOs in Java, the values of these strings are obviously unrestricted because.

Jackson provides built-in support for serializing/deserializing URIs, regexps and a few other meaningful types from strings. We should use these types where possible.

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

Skipping this issue number to maintain synchronization with Google Code issue IDs.

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

Original author: [email protected] (January 07, 2011 10:16:15)

Currently jsonschema2pojo can't deal with schemas that contain a simple type (e.g. string, integer, array, etc) as their root element.

Example schema 1:
{
"type" : "string"
}

JSON data valid against example schema 1:

"abc"

Expected jsonschema2pojo behaviour:

No pojos should be generated. JSON content will be unmarshalled into java.lang.String.

Example schema 2:

{
"type" : "array",
"items" : {
"type" : "object",
"properties" : {
"foo" : {
"type" : "string"
}
}
}
}

JSON data valid against example schema 1:
[{"foo":"bar"}, {"foo":"bar"}, {"foo":"bar"}]

Expected behaviour:

One pojo should be generated. The root construct will be represented in Java by a simple collection (e.g. java.util.List), and the elements of that collection will be instances of the generated pojo.

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

Original author: [email protected] (January 12, 2011 10:47:44)

We're not getting the right de-serialization behaviour at the moment. On attempting to de-serialize using an enum for which the value does not match the Java enum name, I see the following exception:

org.codehaus.jackson.map.JsonMappingException: Can not construct instance of com.example.Item$Type from String value 'myValue': value not one of declared Enum instance names

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

Original author: [email protected] (February 22, 2011 16:33:33)

At the moment we have a fairly dumb way of providing input, you can either specify a file or a directory. Since there's no canonical file extension for json schemas, we just read all files. This is obviously not fantastically convenient if e.g. you have xml schemas and json schemas in the same directory.

It would be good to support the standard includes/excludes style maven properties to filter the input.

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

Original author: [email protected] (December 16, 2010 08:45:49)

com.sun.codemodel.JClassAlreadyExistsException

{
"description":"blah",
"type":"object",
"properties":{
"name":"string"
}
}

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

Original author: [email protected] (January 25, 2012 19:35:34)

There is currently no way to ask jsonschema2pojo to generate the camel case names. This will be great feature.

We should also be abl to specify this as the default on higher level (like the class level) so we don't have to do that for every property.

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

Original author: [email protected] (November 20, 2011 21:59:39)

Need to add this example to the source tree so that it's compiled and updated with every release.

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

Original author: [email protected] (February 22, 2011 12:31:42)

What steps will reproduce the problem?

1. Create a schema using a property that omits the "type" node
2. Create a schema using a property that contains a "type" node with a value that is unrecognised (i.e. not one of the types listed at http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.1).
3. Run jsonschema2pojo with these schemas

What is the expected output?

1. Property that omits "type" should produce property of type java.lang.Object.
2. Property that includes an unrecognised value for "type" should produce a java.lang.Object.

What do you see instead?
Code generation fails in both cases.

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