We've just released 3.146.0, which should address ...

# http4k

[dave]

We've just released 3.146.0, which should address a couple of things with the OA generation:

1. OpenApi 3 schema generation is now compliant using reflection-based mechanism. I have removed the Jackson schema renderer because it was basically useless wth the new changes. Now, if you're passing in Jackson to the OpenApi renderer it will automatically use the reflection solution.

2. @Tom Ellis - I think this should solve your problem in actually a nicer way - there was a bit of an issue with your original solution, in that you need both the object AND the JSON format to correctly generate the schema, because of the way it would treat non-primitive-but-string-represented objects such as Uris, UUIDS etc. Your solution partially recognised this but didn't address all of the possible types. The new implementation is driven primarily from the JSON form (to select the underlying JSON "type" for the schema).

3. Part of the build now is to generate OA2/3 API clients from the generated specs using https://openapi-generator.tech/ . If anyone fancies a little side-project, then creating an http4k client/server generator to plug into this thing would be pretty neat. (I suggest using the excellent KotlinPoet for the code generation process 😉 ).

3. @Nezteb - Map-types are now supported as per issue #228 that you raised - JVM Maps detected in the code will now be generated as objects with an additionalProperties field. It's not exactly as specified in the issue - as in you can only model exact keys or an empty map will become a free-form dictionary type with no constraints - but I think it's probably close enough. And the UI does seem to model it correctly if I'm not mistaken 🙃

4. One thing that is missing is that you can't custom name the objects anymore - they are based on the simple name of the underlying class - it's possible that we could add a naming strategy object so you could custom name the definitions, but that seemed to be a bit tricky to get right when I tried it (because of the recursive nature of the algorrithm). Also, the option to override the "definitionId" field in the route DSL now will not work for the auto-naming, so it might just be that you need to carefully name your model objects.

Anyway, have a play and let us know if this works better, or if anything breaks. 🙂