Undertow: can't apply springdoc-mvc-openapi module

[pascalgrimaud]

When using spring-boot-undertow module, the springdoc-mvc-openapi can't be applied as it's linked only to spring-boot-tomcat

[DamnClin]

I don't see any acceptable solution for that...

[pascalgrimaud]

The current solution is to go to patches page, to bypass the tree

[DamnClin]

Yep but allowing that in landscape will require a lot of work (something with an or in the organization) and I'm not sure this is worth the effort...

[biergit]

Another solution would be to provide the modules selected further down the tree (west side on the landscape) to the modules selected further up the tree. Then there would only be one module springdoc-openapi.
This would also provide a solution for #4111 where zalando-problems could choose the right dependency depending on whether spring-boot-webflux-netty or a servlet container was chosen.

Actually thinking about it some more I think every feature should provide an interface that depending features use to implement their functionality. So e.g. the Java Build Tool feature would abstract over Gradle and Maven and would offer something like addDependency - an interface that the other features down the line like Java Base, Spring Boot would use.
What do you think? I think someone else posted a similar idea somewhere already. The Spring Initializer project should be a good inspiration - interesting to see that they started out with Mustache templates but then moved away from it.

[pascalgrimaud]

Adding a bounty as I think it's important to have, when there are more modules

[murdos]

A solution would to allow a module to declare multiple features.
Here we would like to to have a feature spring-server-mvc so that spring-boot-tomcat and spring-boot-undertow would both implements features spring-server-mvc and spring-server, and springdoc-mvc-openapi would depends on spring-server-mvc.

Or a feature could inherit from another feature: features spring-server-mvc and spring-server-webflux would be children of spring-server feature, and springdoc-mvc-openapi would depends on spring-server-mvc

[DamnClin]

A solution would to allow a module to declare multiple features. Here we would like to to have a feature spring-server-mvc so that spring-boot-tomcat and spring-boot-undertow would both implements features spring-server-mvc and spring-server, and springdoc-mvc-openapi would depends on spring-server-mvc.

Or a feature could inherit from another feature: features spring-server-mvc and spring-server-webflux would be children of spring-server feature, and springdoc-mvc-openapi would depends on spring-server-mvc

Not really since that can't be displayed in the UI (and this is the only goal of features(

[pascalgrimaud]

I think we'll need to fix this ticket, as we'll have the same issue as soon as gradle is implemented. A lot of module will depend on feature 'build tool', instead of maven directly
The feature build tool will contain maven and gradle

[DamnClin]

I think we'll need to fix this ticket, as we'll have the same issue as soon as gradle is implemented. A lot of module will depend on feature 'build tool', instead of maven directly The feature build tool will contain maven and gradle

Probably but that mean we have to find a possible solution. (But there is not problem with Gradle or Maven, totally different case)

[DamnClin]

I still don't understand why we are trying to do complicated stuff here. We ça can just add a feature with empty (or almost empty) modules to choose between reactive and not reactive, that will solve this issue without adding a lot of complexity in the landscape screen

[murdos]

Probably but that mean we have to find a possible solution. (But there is not problem with Gradle or Maven, totally different case)

I was also thinking about the gradle and maven problem, because in my understanding every module adding a maven plugin(s) to the build will need to be split in a maven and gradle flavor (and thus with a dedicated feature), because maven and gradle plugins are always different for achieving a similar feature (contrary to java dependencies).

[DamnClin]

Probably but that mean we have to find a possible solution. (But there is not problem with Gradle or Maven, totally different case)

I was also thinking about the gradle and maven problem, because in my understanding every module adding a maven plugin(s) to the build will need to be split in a maven and gradle flavor (and thus with a dedicated feature), because maven and gradle plugins are always different for achieving a similar feature (contrary to java dependencies).

For this case that probably mean we'll set information for both maven and Gradle in plugins

[murdos]

I still don't understand why we are trying to do complicated stuff here. We ça can just add a feature with empty (or almost empty) modules to choose between reactive and not reactive, that will solve this issue without adding a lot of complexity in the landscape screen

Ok, got it. I've something that seems to be satisfying with empty extra modules.
I'm polishing it and I'll submit a draft.

[murdos]

Bounty claimed: https://opencollective.com/generator-jhipster/expenses/117664

[pascalgrimaud]

@murdos : approved