AnyOf causes code generation problem in icarConsignmentType

[cookeac]

The issue is this clause:

    "originAddress": {
      "description": "Origin address for movement.",
      "anyOf": [
          { "type": "string" },
          { "$ref": "../types/PostalAddress.json" }
      ]
    },

This causes code generation to ONLY generate the PostalAddress version, which is a breaking change from previous versions where only a string was possible. This occurs with openapi-generator v6.

[cookeac]

@AlexeyHardCode pointed out that openapi-generator 6.x generates code that correctly handles this in C#, BUT in an implementation assignments to or reading from originAddress needs to change slightly,
@AndreasSchultzGEA does not think this is as well handled in Java.

We need to decide whether this should be handled as a slightly breaking change with documentation, or reverted so that originAddress and destinationAddress are only strings. If we need to revert, then it would be good to do this in the 1.3.2 patch.

[cookeac]

@AndreasSchultzGEA if you could post a piece of the generated code for originAddress in Java, please, that might help us with our assessment of how significant is the breaking change.

[AndreasSchultzGEA]

    name = "icarConsignmentType",
    description = "Consignment information for a movement (arrival, departure)."
)
@JsonTypeName("icarConsignmentType")
public class IcarConsignmentType {
    @JsonProperty("id")
    private IcarIdentifierType id;
    @JsonProperty("originLocation")
    private IcarLocationIdentifierType originLocation;
    @JsonProperty("originAddress")
    private IcarConsignmentTypeOriginAddress originAddress;
    @JsonProperty("destinationLocation")
    private IcarLocationIdentifierType destinationLocation;
    @JsonProperty("destinationAddress")
    private IcarConsignmentTypeDestinationAddress destinationAddress;
...

[AndreasSchultzGEA]

@Schema(
    name = "icarConsignmentType_originAddress",
    description = "Origin address for movement."
)
@JsonTypeName("icarConsignmentType_originAddress")
public class IcarConsignmentTypeOriginAddress {
    @JsonProperty("addressCountry")
    private String addressCountry;
    @JsonProperty("addressLocality")
    private String addressLocality;
    @JsonProperty("addressRegion")
    private String addressRegion;
    @JsonProperty("postOfficeBoxNumber")
    private String postOfficeBoxNumber;
    @JsonProperty("postalCode")
    private String postalCode;
    @JsonProperty("streetAddress")
    private String streetAddress;

    public IcarConsignmentTypeOriginAddress() {
    }
... 

[AndreasSchultzGEA]

There is no additional Constructor taking a String-Argument created as it seems to be present at C#.

[cookeac]

Here's my suggestion:

• We added the AnyOf PostalAddress option to help those who needed to transfer structured address data that the previous string did not provide. In theory it would have allowed simple strings to be used as well but this doesn't work with Java codegen.
• As I've started specifying a Carcass data event based on the Australian specifications, it would be helpful to have other information about the source or destination facility (including organisational identifiers, tax code, etc).
• I propose that in the short term (version 1.3.2 update) we revert the originAddress and destinationAddress to string.
• Then in version 1.4, we should add a separate, optional, originOrganization and destinationOrganization (US spelling) which could carry additional organisation information as well as the PostalAddress. As it is a separate attribute this won't cause the same code generation issues.

[AndreasSchultzGEA]

reverting the addresses from 1.3 back to 1.2-version implies to change the code again...
Don't all the companies we know already have changed their implementation? Would they like to adjust it again?

If we decide to revert/ change, why in 2 steps instead of one?

[AndreasSchultzGEA]

I'll take this issue to the issue-tracker of OpenAPIGenerator

[cookeac]

During our discussion on 12 Jan 2023 we discussed:

1. Identifying a bug in openapi-generator for Java. This could then be addressed with a workaround such as an openapi-generator option (if available) or manually patching Java code after generation.
2. Reverting the definition of originAddress and destinationAddress to strings (ADE 1.2) and adding more complex organisation objects as proposed in Extensions to Consignment for animals being sent to a processor #359. However we are concerned about introducing more changes to the 1.3.2 patch.
3. Reverting the definition of originAddress and destinationAddress to strings (ADE 1.2) and adding an originPostalAddress and destinationPostalAddress with the structured address. This avoids a breaking change and the code generation problem. It is slightly less elegant but may be better for users.
   In the meantime, Andreas will follow up as noted above.

[cookeac]

On 09 February 2023 we agreed:

• Reverting the definition of originAddress and destinationAddress to strings (ADE 1.2) and marking these as deprecated.
• Adding an originPostalAddress and destinationPostalAddress with the structured address.

This avoids a breaking change and the code generation problem. It is slightly less elegant but may be better for users.