App presets (group of extensions) to ease generating Quarkus apps

[ia3andy]

Starting a discussion about #24657

[ia3andy]

ping @quarkusio/devtools

[aloubyansky]

There could be different approaches here. The simplest one would probably be creating named sets of extension GAs (actually GACTs) and adding them to the platform JSON descriptors. Dev tools could then expose them to the users allowing to be selected, etc.

I wanted to throw out a bit more sophisticated idea I explored once for consideration. Instead of configuring very precise (implementation-based) presets, we could consider more general technology “packs” (allowing alternative implementations, e.g. JDBC drivers, REST, etc). It’s also somewhat related to issues in [1] (where referencing specific extensions in codestart caused an incompatibility issue) and general extension set compatibility checking.
I was wondering about leveraging the capability mechanism https://quarkus.io/guides/capabilities for this. Note, that capabilities are already included in the extension metadata and, given an extension catalog, we know which extension provides which capabilities and which capabilities it requires (if any).

E.g. we know that quarkus-resteasy and quarkus-resteasy-reactive provide capability io.quarkus.rest. And so they are alternative implementations of the REST capability and also can’t be used in the same project.
We could imagine that the JDBC driver extensions would provide capabilities with io.quarkus.jdbc. prefix. E.g. io.quarkus.jdbc.psql, io.quarkus.jdbc.mysql, etc.

An extension pack then could be expressed as a set of capabilities that must be satisfied. It would still have some user-friendly name and be recorded in the platform metadata. E.g. an extension REST+CRUD pack could be configured as requiring capabilities:
io.quarkus.rest
io.quarkus.jdbc.*

Again, given an extension catalog, we know which extensions provide these capabilities. We could either highlight to the user (or offer dropdowns, depending on the UI we come up with) the extensions to choose from to fulfill the chosen pack requirements or pre-select specific implementations. To be able to pre-select specific implementations though, we’d need to specify the default/preferred implementation choice of a given capability, unless a user has already selected one. This would have to be recorded in the platform metadata too.

An advantage of this indirection is that if/when we switch from one preferred impl of a tech to another one (e.g. resteasy -> resteasy-reactive) we wouldn't have to go an update GAs everywhere. We'd simply update the preferred impl of a given capability in the metadata. And I think a similar approach could help with issues in [1].

Whatever the user chooses we’d still perform the capability requirements check for the selected extensions to make sure there are no conflicts and the requirements are satisfied.

[1] #25384

[aloubyansky]

Could you describe how it would break then?

[ia3andy]

Ok, I verified base codestarts override extensions codestarts.

Well it depends,

• When using old CLI with a recent version, you will get the extensions codestarts embeded in that CLI (not broken but not what you would expect)
• When using a recent CLI with an old version, then they will not contain those codestarts, you won't have them.

[maxandersen]

"When using old CLI with a recent version, you will get the extensions codestarts embeded in that CLI (not broken but not what you would expect)"

not following - why would that not be what you expect ?

"When using a recent CLI with an old version, then they will not contain those codestarts, you won't have them."

makes sense to me - groupings is per platform so old platforms won't have them.

[ia3andy]

"When using a recent CLI with an old version, then they will not contain those codestarts, you won't have them."

makes sense to me - groupings is per platform so old platforms won't have them.

I am talking about RESTEasy C and R (which are default) and Spring Web, not having them is a problem IMO?

[maxandersen]

Not following what you mean about "not having them" - what is "them" in that sentence?

I talked about old versions of platform not having groupings. Which I don't see why that is a problem. Can you outline where you think that is an issue ?

[maxandersen]

"It's easy to add a capability though. I think it'd be easier that way than supporting two alternative ways of defining these presets."

if we do that it means we cannot add extensions that don't have capabilites and if we force it on all now everyone has to think really hard about what kind of capability they provide...and why would that not just end up being the exact extension id name for most ?

I still think you would just use capablities when you actually share api/functionallity with multiple extensions ... extensions group should be able to be defined via explicit extensions + capability (with default choice if no other way to decide which of many). Otherwise its too narrow usage.

[aloubyansky]

I am not sure I like mixing capabilities and specific implications (I.e. GAV). Specific implications provide capabilities which we would have to take into account anyway. Also we are thinking of capabilities for a reason here, which is to avoid referencing specific GAVs from codestarts. Given that presets would most probably be limited to particular extensions, imo it wouldn't be a big deal to require a capability for presets.