Add support for http:// URLs when using $ref #87
Comments
|
From [email protected] on February 01, 2013 23:04:25 |
|
From [email protected] on February 02, 2013 13:34:44 I stored these schemas to the src/main/resources/schema. Error is regarding URI scheme, it seems to expect "file". Since the URI is relative (and valid as long the file is in same path than referrer) I would not expect this error. I tried to replace the relative path with absolute URI (to my server) but tool then failed with an error indicating the URI scheme as an authority component... which I do not understand either (tried http:// and https://). Any cue? |
|
From [email protected] on February 02, 2013 13:59:02 Exception in thread "main" java.lang.IllegalArgumentException: URI scheme is not "file" |
|
From [email protected] on February 02, 2013 16:22:09 |
|
From [email protected] on February 02, 2013 16:25:14 Envoy� de mon iPhone Le 2013-02-02 � 11:22 AM, "[email protected]" |
|
From [email protected] on February 02, 2013 17:17:37 |
|
From [email protected] on February 03, 2013 16:01:00 Note that I have to enable the 2 options: "Use draft v3" and "Use id for addressing". I believe this last one might be the cause of the issue in your tool. Attached is a sample json instance that validates successfully against the schema. |
|
From [email protected] on February 03, 2013 20:12:55 "$ref": "http://json-schema.org/draft-03/links#" At present this tool only supports file links so the tool complains that 'URI schema is not "file"' because it has found 'http://' and it can't deal with this ref. It would be nice if the error message included the text of the problematic URI so I'll fix this. You need to download the links schema and use a local reference. Be warned though that the links schema also references both the hyper-schema and core schema. You're going to end up generating Java beans for the whole of JSON Schema, which is probably not a good thing to attempt since many of structural definitions used in the core and hyper schema do not map well to Java. To solve this, I'd personally download the links schema and remove the "schema" and "targetSchema" properties from it. |
|
From [email protected] on February 03, 2013 22:51:09 This sounds to me more of an issue, since usually, the schemas the be implemented cannot be modified (provided by the API provider which the implementation wishes to implement). I see the workaround but would love to this this fixed in a future release. Why would not the structural definitions of the official meta schemas get properly generated? Any specific keywords you do not handle right for now? At least I get the Java files generated with the workaround provided, but I really would like to avoid editing the schemas, which validates fine with JSV. Philippe |
|
From [email protected] on February 03, 2013 23:22:13 Regarding the meta schemas, the difficulties I'm referring to are not really related to keyword support. The biggest problem with mapping the full, official schemas in a meaningful way is that they make extensive use of union types. There are many instances in where these simply can't create a Java type hierarchy that is easily mappable by a JSON binding library like Jackson. The solution here is typically adding library-specific type hints to the JSON being mapped, which something that I think should be avoided. Imagine a simply schema that defines a property that can be either integer or string. How would you elegantly represent this property in Java? (use Object type?). If you need to represent such dynamic data, what benefit are you getting in mapping it to a statically typed API of Java beans? The core schema and hyper-schema are good examples of documents that have been designed with the extensibility and dynamic nature of JSON in mind, by definition they are not considerate of the limitations of Java and static typing. In practice, generating Java types and using data-binding is not a one-size-fits-all solution. If you have very dynamic data (e.g. the structure can vary wildly in ways that repel attempts to define rigid interfaces), sometimes data-binding is the wrong way to go. Putting that aside for now, I understand that it's sometimes not desirable to change a provided schema. Thinking for a moment about the users of your generated types though, is it really desirable to create Link beans whose interface depends on a large hyper-schema type, which in turn depends on a much larger set of types representing the core schema? These seem largely irrelevant to your Java-based representation of Links. |
|
From [email protected] on February 05, 2013 01:40:54 I agree with you that referring to complete link description types Do you have ETA about supporting the
Any chance to see this coming -even experimental- in 0.3.5? |
|
From [email protected] on February 05, 2013 16:03:02 |
|
From [email protected] on February 05, 2013 17:13:20 Thanks a bunch! |
|
From [email protected] on February 05, 2013 19:40:53 http://code.google.com/p/jsonschema2pojo/issues/detail?id=85 And the Milestone labels here: http://code.google.com/p/jsonschema2pojo/issues/list Cheers |
|
From [email protected] on February 09, 2013 18:22:04 |
|
From [email protected] on February 13, 2013 14:47:15 Looking at the code of jackson, it looks like a bug since the code is doing the exact same thing if there is a space (%20). Second, My eclipse had problems parsing the poms in jacsonschema2pojo because the plugins section is not enclosed by a pluginManagement section. It was throwing a cryptic error : Appart from theses 2 issues, The new feature looks to be working in the maven plugin. |
|
From [email protected] on February 13, 2013 21:05:14 Regarding the space in the name, could you give me a demonstration of exactly what input you are using (example pom, example schemas). We may simply have to live with this as a known limitation until it's fixed upstream in Jackson, but I'll take a look and see if there's anything I can do. Regarding the m2e error: "maven-dependency-plugin (goals "copy-dependencies", "unpack") is not supported by m2e." this garbage produced by m2e 1.0 and later. I'm loathe to introduce IDE-specific extras into the poms but I believe you can fix this by adding an Eclipse-specific 'lifecycle-mapping' plugin configuration into the pom. Google the error and you will find a load of links and explanation. Try the top accepted answer here for a solution: (I don't intend to add this m2e cruft into the project though and I still hold out hope that Sonatype will address this themselves). |
|
From [email protected] on February 13, 2013 22:24:26 |
|
From [email protected] on February 13, 2013 23:29:34 Thanks! |
|
From [email protected] on February 13, 2013 23:36:58 Check the downloads area or update your plugin version if using maven. |
|
From [email protected] on February 15, 2013 21:10:34 |
|
From [email protected] on June 14, 2013 07:28:27 Failed to execute goal com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.3.6:generate (default) on project json-tool: Execution default of goal com.googlecode.jsonschema2pojo:jsonschema2pojo-maven-plugin:0.3.6:generate failed: Unrecognised URI, can't resolve this: file:/files/06%20Workspaces/ws_android/json-tool/src/main/resources/schema/ticket.schema Correct file name on linux is: /files/06\ Workspaces/ws_android/json-tool/src/main/resources/schema/ticket.schema |
|
From [email protected] on June 19, 2013 22:04:34 |
Original author: [email protected] (February 01, 2013 22:51:08)
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
The text was updated successfully, but these errors were encountered: