Possible circular dependency on TS29571_CommonData.yaml (go 1.18)

[uri200]

Hello
I am using Rel-17 Dec'21 version from Jan 3

I may be wrong, but it looks like TS29571CommonData and TS29510_Nnrf_AccessToken depend on each other, so there seem not be a way to generate them (at least for for GO).

In previous versions TS29571CommonData did not depend of any other spec and it could be built independently. But that doesnt work anymore. Am I missing anything

Just in case, this is the command I am using is

//go:generate oapi-codegen -generate types,skip-prune -o specs/TS29571CommonData/TS29571CommonData.gen.go --import-mapping TS29510_Nnrf_AccessToken.yaml:magma/feg/gateway/sbi/specs/TS29510_Nnrf_AccessToken defs/TS29571_CommonData.yaml

go version go1.18 linux/amd64

[jdegre]

Hi Oriol,
Yes, you are correct, both 29.571 and 29.510 API make reference ($refs) to each other. This is something allowed by the OpenAPI spec, and the resolution works fine. This is not even a case of "circular reference", it just happens that there are schemas in each file referencing to schemas in the other file.

As it seems, this creates a problem on code generators, unfortunately. I really don't know how to solve that, other than reporting the issue in their repository and hope that they make some enhancement to address the issue.

A possible workaround I can think of is to pre-process each file with a "bundling" tool. E.g. (swagger-parser; see the "bundle" function there ("Bundles all referenced files/URLs into a single api that only has internal $ref pointers.").

After that, you can feed the output file into the code-generator. I don't know... just a thought...

[uri200]

Thanks @jdegre note that swagger-codegen worked for me finally. I was not able to use other codegens though due to that circular ref.