Improve the add-extensions partial match approach

[emmanuelbernard]

Today the following algorithm is used:

For each entry in -Dextensions do the following:

1. look for extensions with exactly matching tags. e.g. a dep with tag abracadabra will match -Dextensions=abracadabra
2. look for exensions whose name includes the query in lowercase e.g. Quarkus AbrAcadabra will match -Dextensions=brac
3. look for exensions whose artifact id name includes the query in lowercase e.g. quarkus-abracadabra will match -Dextensions=brac
4. if there is more than one extension matching, then none is picked and the user sees the list
5. any full GAV is added

Right know it creates conflicts:

• you must use the GAV to select quarkus-hibernate-orm because there is quarkus-hibernate-orm-panache
• you must use the GAV to select arc because quarkus-hibernate-search-elasticsearch conrtains arc

I propose the following refinements:

A search command whether via start.quarkus.io or the -Dsearch would keep the previous algorithm as it maximizes the number of relevant matching entries

The -Dextensions algorithm should aim at:

1. allowing partial typing to find a match
2. limit to resort to GAV to disambiguate.

Here is a set of change proposal that we can partially or entirely take

1. remove search for tags: I'd like to see when a search via tag would lead to a unique extension match
2. make an exact artifactId match have priority and lead to a single selection even if the algorithm otherwise find several matches
   • consider foobar an exact match of quarkus-foobar
   • but if two extensions with the same artifactId and two different groupId are matching, ask the user to disambiguate

Rule 2 would offer a way out of two conflicts mentioned above:

• someone writing arc would not have to select the GAV
• someone writing orm would have to choose between panache and normal ORM
• someone writing hibernate-orm would select orm and not panache

[emmanuelbernard]

@gsmet Here are my rule change proposal to limit name conflicts and offer a simpler way out than having to write the GAV. I'm interesting to see what hope you can poke at it.

[gsmet]

Looks good to me. Let's try to tackle that for 0.17.0.

[FroMage]

LGTM too

[emmanuelbernard]

I'm adding a new use cases to it. Some extensions have a very very bad "SEO" because their artifactId is long and painful to write down. It would lead to other extensions or approaching being de facto preferred instead of what would be the more natural path for a Quarkus app.
To fix that, we want to explore the notion of a shortname for extensions (to be added in the JSON file).

That short name is:

• globally unique across all extensions, or at least as unique as artifactId are,
• ?should shortname be unique within the artifact id scope to?

Short name should not be abuse and use only when it's important. A good artifactId is preferred.
Short name match would be exposed to the user experience in two ways possible ways:

1. it would qualify as an exact match having priority over partial matches like artifactId is (see above)
2. it would not qualify as a exact match having priority but rather be the default proposed choice in the list of options shown
   • this means that the CLI (maven, gradle and CLI) need to be adapted to offer a prompt choice upon ambiguity and propose the short name as the default choice when applicable
   • on the website, the shortname would be exposed by it being return first in the auto-completion list upon partial match

Let's take an example.

• io.quarkus:quarkus-smallrye-reactive-messaging-kafka
• io.quarkus:quarkus-kafka-streams

with the shortname kafka be assigned to quarkus-smallrye-reactive-messaging-kafka

-Dextensions=kafka would offer

• in 1. to select io.quarkus:quarkus-smallrye-reactive-messaging-kafka automatically for the user
• in 2. to offer both but preselectionning io.quarkus:quarkus-smallrye-reactive-messaging-kafka

-Dextensions=kafka-streams would offer io.quarkus:quarkus-kafka-streams

CC @cescoffier @n1hility

[emmanuelbernard]

On a side note, I wonder if we should consider quarkus-smallrye- as an optional prefix just like quarkus- is today. Or whether that would lead to problems.

[kenfinnigan]

Could do. In theory there shouldn't be overlap, otherwise it means we're duplicating effort in different places

[emmanuelbernard]

I not following your effort duplication argument @kenfinnigan

[kenfinnigan]

If we have a quarkus-smallrye-{something} and a quarkus-{something} then it likely means {something} is implemented both in SmallRye and Quarkus, which would be duplicating effort.

[emmanuelbernard]

Ah I get your meaning now.

[cescoffier]

I'm on it, trying to see the corner cases.

[gsmet]

I'm keeping the issue open for now as I'm not sure everything was implemented as it was supposed to be.

Feel free to close it if everything is in order.

[cescoffier]

Closing as this has been fixed a long time agon