Schema Attributes with #

[Solksjaer]

trafficstars

After updating to version org.jsonschema2pojo:jsonschema2pojo-gradle-plugin 1.1.2 of the plugin, we are no longer able to generate classes when the attributes contain # This was possible on version 1.1.1 For example VERSV#

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "$ref": "#/definitions/BusinessData",
  "definitions": {
    "BusinessData": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "VERSV#": {
          "type": "string"
        },
        "HEADER": {
          "$ref": "#/definitions/Header"
        }
      },
      "title": "BusinessData"
    }
}

[joelittlejohn]

Interesting. I assume in the past you got a java property named like versv_? Not sure what has caused this but this isn't an expected change. We have any test using this kind of name so we should add one.

[Solksjaer]

actually, the property is named just versv (although we could potentially rename it, if the code generation prefers other kind of nomenclature). The biggest issue would be the input data, because we don´t have control over it and the # properties appear in different places. Thanks for taking a look at it

[prndrsn]

Is there any roadmap for when a version containing the fix for this will be released? This issue breaks code generation from redfish schemas (example property name: "#Chassis.Reset") and in our case, this has unfortunately had a huge side effect of blocking Java EE to Jakarta migration as we are unable to uplift jsonschema2pojo so we can generate jakarta-annotated classes.

If there is no new jsonschema2pojo release on the near horizon, is there any way for us to work around this? I guess we could patch FragmentResolver and SchemaStore ourselves in-house or use jsonschema2pojo built from the latest source but we would like to avoid that if possible as both alternatives would have impact on our processes and CI. Using an unreleased version might potentially not even be an option at all. We also have no control over the input, so schema changes are not an option either.

[joelittlejohn]

@prndrsn I revisited this fix over last weekend. I had to rethink the solution to be more complete. I will try to get out a new version that includes this fix this week, as we have quite a few unreleased changed now.

[unkish]

Slight OT: should we close #1407 as duplicate of #1402 ?

[prndrsn]

@joelittlejohn That is very excellent news, thank you for the quick response.