Question
I'm trying to parse 2 API Specifications in OpenAPI 3.0.3 using OpenApiGenerator version 7.1.0. One has the TO (lets call it BrokenTO) directly as response object, the other one has a TO (lets call it ObjectThatContainsBrokenTO) that includes the TO from the first API. This results in ObjectThatContainsBrokenTO having a reference to BrokenTO_1 not BrokenTO. The other API Spec parses correctly with BrokenTO reference.
I already verified the paths to the object in question are the same. I also tried putting both TO yaml descriptions into the same folder so the path is exactly the same
Affected Version
2.1.36 from the OpenAPI Generator
Context
openapi: 3.0.3
info:
title: Our API
version: 1.0.0
tags:
- name: SomeTag
paths:
/classified/path/:
$ref: "ClassifiedAPI.yaml"
/another/classified/path:
$ref: "Classified2APIyaml"
#ClassifiedAPI.yaml
post:
operationId: anotherOperationId
parameters:
requestBody:
content:
application/json:
schema:
$ref: 'ObjectThatContainsTheBrokenTO.yaml'
#ObjectThatContainsTheBrokenTO.yaml
type: "object"
properties:
aparameter:
$ref: "aTO.yaml"
anotherparameter:
$ref: "anotherTO.yaml"
parameterinquestion:
type: "array"
items:
$ref: "../folder/folder2/BrokenTO.yaml"
#Classified2APIyaml
get:
operationId: someoperation
parameters:
# some parameters
responses:
'200':
description: Ok!
content:
application/json:
schema:
$ref: "../folder/folder2/BrokenTO.yaml"
Additional Details
These yaml definitions are generated as the BrokenTO.java class but also as a reference to BrokenTO_1 is generated into the Java files for ObjectThatContainsTheBrokenTO.java.
While debugging the generator code I found a difference in how the $refs are created and later stored in the cache. One time it has a leading ./ but the other time it has not.
Question: Why is the path prefixed with ./ in one case but not the other?
Follow up: Couldn't all paths be prefixed with ./ since it does not make a difference? To be extra sure the file is the same a hash could be used to verify the content is identical. Would you agree with that? Is that something for a PR?
I found the following discussions/issues but nothing that matched my use case and/or resolved it:
#1081 (comment)
OpenAPITools/openapi-generator#2701
OpenAPITools/openapi-generator#20454
Thanks :)
Checklist
Question
I'm trying to parse 2 API Specifications in OpenAPI 3.0.3 using OpenApiGenerator version 7.1.0. One has the TO (lets call it BrokenTO) directly as response object, the other one has a TO (lets call it ObjectThatContainsBrokenTO) that includes the TO from the first API. This results in ObjectThatContainsBrokenTO having a reference to BrokenTO_1 not BrokenTO. The other API Spec parses correctly with BrokenTO reference.
I already verified the paths to the object in question are the same. I also tried putting both TO yaml descriptions into the same folder so the path is exactly the same
Affected Version
2.1.36 from the OpenAPI Generator
Context
Additional Details
These yaml definitions are generated as the BrokenTO.java class but also as a reference to BrokenTO_1 is generated into the Java files for ObjectThatContainsTheBrokenTO.java.
While debugging the generator code I found a difference in how the $refs are created and later stored in the cache. One time it has a leading ./ but the other time it has not.
Question: Why is the path prefixed with ./ in one case but not the other?
Follow up: Couldn't all paths be prefixed with ./ since it does not make a difference? To be extra sure the file is the same a hash could be used to verify the content is identical. Would you agree with that? Is that something for a PR?
I found the following discussions/issues but nothing that matched my use case and/or resolved it:
#1081 (comment)
OpenAPITools/openapi-generator#2701
OpenAPITools/openapi-generator#20454
Thanks :)
Checklist