Luciano Vernaschi

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

3

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...

Generator maps fields, even private ones, and ignores bean properties

2

In Hilla 1.1, the generator creates TypeScript files by matching fields in the Java class. Consider for example this entity: ```java public class MyEntity { private int num = 3;...

Generator outputs `undefined` as a possible return type for endpoint methods calling `client.subscribe`

2

In Hilla 1.1, when generating TypeScript endpoints with `Flux` return types (i.e. push), the return type includes `undefined`. For example, this code: ```java public Flux getAllUsers() { return Flux.just(); }...

(feat) use multi-module generator in integration tests

2

## Description The tests using `flow-maven-plugin` now use `generator-maven-plugin` and the build process is adapted to allow it to run. The plugin replacement should be discussed as by doing so,...

Multi-module generator fails on `reactor.core.publisher.Flux`

3

While searching for the dependencies of `public org.reactivestreams.Publisher apply(java.util.List>)`, the generator seems unable to resolve `V`: ``` ... Caused by: java.lang.IllegalArgumentException: Could not resolve V against parameters of the defining...

The multi-module generator does not support using a custom client

1

The `endpoints-custom-client` test module fails when using the multi-module generator as it doesn't pick up the provided custom client. It should mimic the existing feature as implemented at https://github.com/vaadin/hilla/blob/42ea5619a0d670b39ef330be68caaf0423c37ad0/packages/java/endpoint/src/main/java/dev/hilla/frontend/TaskGenerateEndpointImpl.java#L50-L54

When the `x-class-name` extended property is created in the OpenApi definition during parsing, its value contains the name of the original class. It should contain the name of the transformed...

Cannot run a project containing endpoints without parameter names in class files

1

When the project containing the endpoints is compiled without the `parameters` flag, ClassGraph always returns `null` as parameter name, whereas Java reflection generates `argN` placeholder names. While it is recommended...

fix: generate default parameter names when they are not available in compiled classes

2

Fixes #571 by adding a `getIndex` method in `MethodParameterInfoModel` and its subclasses, and using that method to generate missing parameter names in the form `argN`.

fix: support the `@EndpointExposed` annotation in the multi-module engine

3

Fixes #512