Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration option to use Joda types #110

Closed
joelittlejohn opened this issue Jun 23, 2013 · 8 comments
Closed

Configuration option to use Joda types #110

joelittlejohn opened this issue Jun 23, 2013 · 8 comments

Comments

@joelittlejohn
Copy link
Owner

Original author: stackma...@gmail.com (June 17, 2013 12:30:45)

Given a normal simple type declaration like { "type": "string", "required": "true", "format": "date-time" }, I would like to use joda-time instead of the jvm date types. I've tried several ideas like using org.joda.time.DateTime for the value of type (will result in Object as type) or an additional javaType (will generate a new DateTime class) or format (will result in String as type)

Is there a way to reference any other pre-existing java type? If not, would you consider implementing this?

Thank you
Patrick

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

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on June 17, 2013 20:21:48
You could probably work around this using:

{ "type" : "object", "javaType" : "org.joda.time.DateTime" }

but I realise this is not a particularly pleasant change to have to make to your schemas.

I think a new config argument that instructs the plugin to use Joda DateTime values might be a good idea. Of course you need to include the Joda module if you want these values to be serializable by Jackson, but I see no reason why this shouldn't be available as a config option.

@joelittlejohn
Copy link
Owner Author

From stackma...@gmail.com on June 17, 2013 21:35:11
I'm quite certain this is one of the many combinations I have tried and it didn't work a few hour ago - now it does...

thank you

@joelittlejohn
Copy link
Owner Author

From stackma...@gmail.com on June 17, 2013 22:54:44
Ah no it doesn't. The problem is, that a class org.joda.time.DateTime will be generated. I also found this at the very end of the reference: "The javaType property also allows existing Java types to be used in your POJOs. [...](a new Java type will not be generated)."

So it's a bug, then ;)

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on June 17, 2013 22:55:52
Do you have org.joda.time.DateTime on the classpath of the project? This is required for the plugin to be aware of DateTime as an existing type.

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on June 19, 2013 22:06:40
Patrick, have you tried this again with Joda on the classpath?

@joelittlejohn
Copy link
Owner Author

From stackma...@gmail.com on June 20, 2013 08:28:48
Yes, I tested a few other options (I'm using gradle and the jsonSchema2Pojo plugin btw). JodaTime is on the project's classpath alright. My latest hack was then to just remove all files outside of my own packages after generating and before compiling.

Now the actual solution is to add joda-time to the buildscript classpath too, then it'll behave as desired.

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on June 20, 2013 16:24:05
I think it's worthwhile letting Ben Manes know that he should document this or make some changes to the Gradle plugin to solve this classpath issue.

The Maven plugin explicitly resolves the project's compile classpath and adds it to the plugin execution to workaround this problem. The Ant task also offers a solution, in that it allows you to explicitly provide additional classpath elements as arguments of the task.

@joelittlejohn
Copy link
Owner Author

From stackma...@gmail.com on June 20, 2013 19:36:34
I'll let him know. Thanks for your help and the project itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant