quarkus-bot[bot]
commented
3 years ago /cc @evanchooly, @geoand, @matejvasek, @patriot1burke
Closed FroMage closed 3 years ago
quarkus-bot[bot]
commented
3 years ago /cc @evanchooly, @geoand, @matejvasek, @patriot1burke
FroMage
commented
3 years ago Sorry everyone, bot went a bit overboard with CC here :)
TomasHofman
commented
3 years ago Hello @ebullient, can I take a look at this or do you have it already fixed in your work?
ebullient
commented
3 years ago It was on my list now that the basics are all put back together again after rearranging the insides. I didn't bother trying to fix it right away, as just getting all the stuff I dumped on the floor back into place again was more important. ;)
TomasHofman
commented
3 years ago Whatever you like, I can do it for you so you can do other stuff or leave it to you. I don't think this should be too complicated however, so I won't save you that much time... :)
ebullient
commented
3 years ago Yea. I was just having a look again.. I certainly don't have to do this myself! What I was wondering is how far back up the tree this should go.. could keep it just in the CLI, or could go back up into command handlers (and watch the fork to gradle.. which a cursory look is telling me I'd have to stare at more).
@aloubyansky -- do you have a preference?
(@TomasHofman .. I'm happy for you to pick this up, is what I'm saying. ;) )
TomasHofman
commented
3 years ago I was looking into the ListExtensionsCommandHandler, as that would make the output sorted both in maven and CLI. I don't think it's worth keeping the current order in some tools as it seems mostly random. Haven't checked Gradle yet.
aloubyansky
commented
3 years ago Another idea would be to use the categories (available in the extension catalog api) in a similar way they are used on code.quarkus.io.
TomasHofman
commented
3 years ago In which case can we add a command to list the categories, and a switch to limit list output to a specific category? :)
aloubyansky
commented
3 years ago That is surely an option. I think displaying the whole catalog may be too much. I guess what we should be looking into is displaying extensions that satisfy some criteria. E.g. a category, key words, native support, etc.
TomasHofman
commented
3 years ago I will take a closer look and come with some proposal. Thanks!
TomasHofman
commented
3 years ago Hello,
one thing to note is that we already have the --search parameter which limits the extension list by searching for names, artifactIds and keywords (I think it doesn't search in category names).
I would like to add following:
qs extensions categories [--id|--full]
Output formats:
--id (default) would list only category IDs--full would list ID, name and descriptionI think the short name could be cats, if it's not too weird.
Usage:
[thofman@rama project]$ qs extension categories --help
Usage: quarkus extension categories [-Beh] [--dryrun] [--[no-]registry-client]
[--verbose] [--id | --full]
List existing extension categories.
-e, --errors Display error messages.
--verbose Verbose mode.
--[no-]registry-client
Use the Quarkus extension catalog
-h, --help Display this help message.
-B, --batch-mode Run in non-interactive (batch) mode.
--dryrun Show actions that would be taken.
Output format
--id Display category ID only. (default)
--full Display category ID, name and description columns.Short format:
[thofman@rama project]$ qs extension categories
alt-languages
cloud
compatibility
core
data
messaging
miscellaneous
observability
reactive
security
serialization
web Full format:
[thofman@rama project]$ qs extension categories --full
Category Id Description
Alternative languages alt-languages Support for other JVM based languages
Cloud cloud Useful for Cloud Native deployments platforms like Kubernetes and cloud providers
Compatibility compatibility Support for alternative programming models on Quarkus
Core core Core Quarkus components: engine, logging, etc.
Data data Accessing and managing your data (RDBMS, NoSQL, caching, transaction management, etc)
Messaging messaging Send and receives message to various messaging systems (AMQP, KAfka etc)
Miscellaneous miscellaneous Mixed bag of good stuff
Observability observability Metrics, tracing, etc
Reactive reactive Non blocking stack and connectors
Security security Everything you need to secure your application
Serialization serialization Serializing and deserializing various formats
Web web Everything you need for REST endpoints, HTTP and web formats like JSONby adding the --category parameter:
qs extension list --installable --category web
I don't think it's necessary to make the --category and --search parameters mutually exclusive, so it could be possible to combine them.
Usage:
[thofman@rama project]$ qs extension list --help
Usage: quarkus extension list [-Behi] [--dryrun] [--[no-]registry-client]
[--verbose] [-c=CATEGORY_ID] [-s=PATTERN] [--name
| --concise | --full | --origins]
List platforms and extensions for this project.
-e, --errors Display error messages.
--verbose Verbose mode.
--[no-]registry-client
Use the Quarkus extension catalog
-h, --help Display this help message.
-B, --batch-mode Run in non-interactive (batch) mode.
--dryrun Show actions that would be taken.
-i, --installable Display installable extensions.
-s, --search=PATTERN Search filter on extension list. The format is based
on Java Pattern.
Default: *
-c, --category=CATEGORY_ID
Only list extensions from given category.
Default:
Output format
--name Display extension name only. (default)
--concise Display extension name and description.
--full Display concise format and version related columns.
--origins Display extensions including their platform origins.Listing:
[thofman@rama project]$ qs extension list -i -c alt-languages --full
Status Extension ArtifactId Updated Version Guide
Kotlin quarkus-kotlin https://quarkus.io/guides/kotlin
Scala quarkus-scala list command by category?Some of the extensions have more than one category, so if we wanted to "group" the extension list by categories, it would:
grep specific extension names.So I think I would rather not do this, or maybe only do this for --full format.
extension list in CLI mode?Maybe something like:
To list only extensions from a specific category, use:
qs extensions list -i -c <category-id>To search for extensions by a keyword, use:qs extensions list -i -s <keyword>
I'm not sure if the hints could be printed to stderr rather than stdout, to not interfere with standard output if somebody wants to pipe it to some tooling.
ebullient
commented
3 years ago Good suggestions!
I like the flow of 1 & 2. I don't know if cats is weird or not? We can start there and see how it feels. @FroMage .. thoughts?
I also agree with your assessment of 3. I'd like @aloubyansky to chew on this, as we sort out how to deal w/ the registry.. but what you're suggesting for 1 & 2 is nice.
I'm not sure if the hints could be printed to stderr rather than stdout, to not interfere with standard output if somebody wants to pipe it to some tooling.
-B (batch mode) can suppress that output when used with tooling, if we don't want to fuss w/ out vs. err.
FroMage
commented
3 years ago I like this, yes. cats feels weird, though. do we have to have a short name? would categ be better?
ebullient
commented
3 years ago Can we just use cat?
quarkus ext cat is ok
FroMage
commented
3 years ago Ask for another person's opinion. My opinion as a long-time UNIX person is that cat is neither about the animal, nor abot categories, but about typing :(
So I'd find this confusing, but I'm biaised, so let's ask for someone else's opinion to make sure?
aloubyansky
commented
3 years ago About the full/unfiltered list, I think, simply ordering alphabetically (the names or artifactId) could be ok for a start. I am not sure the full list will be the primary use-case, given that it probably will be pretty long, however if a user requests it, it should be sorted. So we could postpone implementing the 3rd option until there is a clear need for it.
TomasHofman
commented
3 years ago @aloubyansky I agree, scratching point 3. :)
@FroMage @ebullient what about qs ext ctgr for a shortcut?
Or maybe not use the word "category", but rather use "group" / "grp" (and --group / -g for a parameter)? I'm not sure if the word "categories" is already exposed to users at other places which would require us to stay consistent... On the web "categories" do not seem to be mentioned.
aloubyansky
commented
3 years ago The issue is that category has been in the JSON and the Java API since the very beginning of Quarkus.
ebullient
commented
3 years ago I think within context, qs ext cat is fine as a short form for category (tab complete would expand to category).. I know @FroMage didn't like it, but it wouldn't be used w/o the surrounding context ..
TomasHofman
commented
3 years ago OK, I'm going to go with cat. I too think that within the context of the command it should be understandable.
Another one - I noticed we mix using short property names like "searchPattern" and long ones like "quarkus.extension.format" in the ListExtensionsMojo (user can set -DsearchPattern=keyword, but -Dformat=full doesn't work, needs to be -Dquarkus.extension.format=full):
@Parameter(property = "quarkus.extension.format", alias = "quarkus.extension.format", defaultValue = "concise")
protected String format;
@Parameter(property = "searchPattern", alias = "quarkus.extension.searchPattern")
protected String searchPattern;Should we stay consistent and use short names only? I haven't noticed any other Mojo using the prefixed properties, it's just this one...
Note that the "alias" field is an alias for XML configuration element in pom.xml, not an alias for -D property. I would say we don't need these aliases at all, as there is little ambiguity about elements in plugin configuration in pom.xml.
TomasHofman
commented
3 years ago Pull request with current version: https://github.com/quarkusio/quarkus/pull/17765
I will be away from Thursday until the end of the week, so I want to show what I have. Functionally it has everything I wanted anyway, but I guess we will discuss / modify details...
TomasHofman
commented
3 years ago This should be resolved by https://github.com/quarkusio/quarkus/pull/17765.
I can't make sense of what the order is supposed to be here:
It's also a bit confusing that some extensions start with
quarkus-while others don't.