Add support for reactive in the server extension

[carlesarnal]

Many thanks for submitting your Pull Request ❤️!

Please make sure that your PR meets the following requirements:

• You have read the contributors guide
• Your code is properly formatted according to our code style
• Pull Request title contains the target branch if not targeting main: [0.9.x] Subject
• Pull Request contains link to the issue
• Pull Request contains link to any dependent or related Pull Request
• Pull Request contains description of the issue
• Pull Request does not include fixes for issues other than the main ticket

This PR introduces support for generating reactive code using the server extension

[hbelmiro]

Thank you @carlesarnal.

It seems like you're confusing the new dependencies for the classic and reactive implementations.
See https://quarkus.io/guides/rest-migration#dependencies.

RESTEasy Classic is still known as RESTEasy (quarkus-resteasy)
RESTEasy Reactive now is Quarkus REST (quarkus-rest).

I suggested changes to the pom.xml files.

---

I also suggest using Maven Profiles to avoid test duplication. With that, you can have just one module and set a flag to run them with each profile (classic or reactive).
We do that in the client module.

That's all you need since all the tests are identical for both implementations.
In case we need specific tests for each implementation in the future, we can use the org.junit.jupiter.api.Tag, like we did here.

Our CI already handles both profiles. See, for example, the job for the reactive profile.

[carlesarnal]

Thank you @carlesarnal.

It seems like you're confusing the new dependencies for the classic and reactive implementations. See https://quarkus.io/guides/rest-migration#dependencies.

RESTEasy Classic is still known as RESTEasy (quarkus-resteasy) RESTEasy Reactive now is Quarkus REST (quarkus-rest).

I suggested changes to the pom.xml files.

I also suggest using Maven Profiles to avoid test duplication. With that, you can have just one module and set a flag to run them with each profile (classic or reactive). We do that in the client module.

That's all you need since all the tests are identical for both implementations. In case we need specific tests for each implementation in the future, we can use the org.junit.jupiter.api.Tag, like we did here.

Our CI already handles both profiles. See, for example, the job for the reactive profile.

Tests are not exactly identical (the test class is). There are two different implementations in the Java projects one reactive and another non-reactive, and, if I merge them both into a single module, it will fail. I can make the tests use profiles to align with the rest of the project, but I don't think it's feasible to merge both modules.

[hbelmiro]

@carlesarnal I see. I don't see a benefit in using profiles then.