Hey QP - maybe you can help. Seems that we currently can't even use the generated code because it simply fails to compile with missing class (same for Ash):
import org.openapitools.client.model.OneOfScheduleInterval; Seems that it comes from this bug in the OpenApi generator : https://github.com/OpenAPITools/openapi-generator/issues/1709 ( 1.5 year old) as a result of this: schedule_interval: oneOf: - $ref: '#/components/schemas/ScheduleInterval' readOnly: true Is this something you can have a look at and see if it can be workaround maybe? Since you contributed to the generator - is it well regarded as "good" in general (seems so)? It seems that this the only problem we have for now (well there is another with "key" variable name but we can easily solve it). Is this just a weird /complex way of our API definition that we can simplify /change/improve? We are not very far from having the client compile so I would love to try to get it working out-of-the-box. J. On Sat, May 30, 2020 at 11:31 AM Jarek Potiuk <jarek.pot...@polidea.com> wrote: > Ash - QP: also - as Kamil mentioned he already generated multiple clients > in https://github.com/mik-laj/airflow-api-clients/tree/master/out/object > so if you have time , maybe you can also take a look in parallel. > > On Sat, May 30, 2020 at 11:29 AM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > >> Kamil - I believe you already have those clients generated - so i will >> use them from there. >> >> J,. >> >> On Sat, May 30, 2020 at 11:26 AM Jarek Potiuk <jarek.pot...@polidea.com> >> wrote: >> >>> OK. Indeed there seem to be quite some ambiguities and inconsistencies >>> and the knowledge we are basing our discussion on is a bit fragmented >>> and "abstract". >>> >>> Sorry for being a bit pushy but I think we are not doing enough as a >>> community to make life our users easier, and we sometimes seem to >>> proceed without fully understanding of consequences for them - >>> downplaying the importance of it. And for public API I think this is a >>> very important topic. >>> >>> I think there is an easy way to get a better understanding - simply >>> use the OpenAPI generator to generate both - clients (in a few >>> languages) and server stubs (in python) for Airflow and become the >>> "user" and try to use the client + server and see where we get from >>> there. This will haunt us for a long time if we make the wrong >>> decision here. >>> >>> For me - this is one of the most important factors on how easy it will >>> be for someone to use the API once we release it. And being able to >>> use generated clients in several languages is pretty much >>> non-negotiable requirement for the API. >>> >>> I will spend some time over the weekend trying it out and see whether >>> the problems that I pointed out are really present in our specs and if >>> they are - whether can be solved quickly - and if there are problems >>> and they need some workarounds or customizations - for me it's super >>> important that we are aware of those problems and we let the users of >>> our API know how to solve them >>> >>> I will be posting some results while I do so - I count on your help QP >>> and Ash if I see any non-obvious obstacles. >>> >>> J. >>> >> >> >> -- >> >> Jarek Potiuk >> Polidea <https://www.polidea.com/> | Principal Software Engineer >> >> M: +48 660 796 129 <+48660796129> >> [image: Polidea] <https://www.polidea.com/> >> >> > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/> > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
