Multi-module generator: leak of classes in the generated OpenAPI

[cromoteca]

When using the multi-module generator in the tests/spring/security module, many classes are added to the components sections of the OpenAPI definition. Those classes are not used by the endpoints to exchange data, but they are added anyway. They come from Spring, Reactor and so on.

Furthermore, the generator is not able to cope with some of those classes, thus making impossible to run the tests.

Let's take for example the Balance endpoint: if BankService is removed and methods are kept by returning dumb values, that endpoint is generated correctly and does not add all those classes to the list, which otherwise are not generated correctly. Same applies to the other endpoints.

Here's the generated OpenAPI: security-openapi.zip

[platosha]

Suggestions for the implementation after a team discussion:

• Avoid private and protected members
• For endpoints, never consider fields
• For entities, only consider properties (sets of getter methods)

The aim is to be more aligned with how Jackson works in runtime.

[cromoteca]

I opened issue #495 on the Hilla 1.1 generator to describe how it works. Basically, fields are used to generate corresponding TS files and everything (fields and properties) is sent to the client as return. While that's quite of a bug to me, but if we have to do the same in the engine, that should be discussed again.

[cromoteca]

Also, considering that Hilla users definitely put annotations on fields, I'm afraid we have to keep using them.