quarkus cli plugin mechanism

[maxandersen]

Description

add ability to do quarkus someplugin (args) that will lookup in PATH for quarkus-someplugin(.cmd) and quarkus-* jbang aliases

Implementation ideas

meachnism lets you write and deliver plugins independently.

Example of usecases: quarkus upgrade to detect and apoly changes, quarkus scaffold / quarkus jhipster for doing codegeneration actions.

[quarkus-bot]

/cc @ebullient, @gsmet, @quarkusio/devtools

[maxandersen]

idea from chatting with @iocanel :

have the traditional convention to look for quarkus-deploy-gcloudin PATH when user does quarkus deploy gcloud
but in addition do a lookup in .jbang/jbang-catalog.json to find locally to the project installed scripts.

To allow version alignment of project and "plugins" a call to quarkus deploy gcloud would set -Dquarkus.version and QUARKUS_VERSION env var to allow the plugin mechanism (i.e. jbang) or even the plugin itself to change behavior based on the version without having to load the quarkus project.

example for jbang-catalog (Not tested!) you could do:

quarkus plugin install quarkus-deploy-gcloud which would make an entry in jbang-catalog similar to:

jbang alias add -f . quarkus-deploy-gcloud@quarkusio/${quarkus.version:2.14.Final}

[iocanel]

After playing with it for a while and discussing with @maxandersen here are some additional thoughts

• CLI plugins should be explicitly enabled.
• CLI plugins should be enabled by adding them to a user or project catalog (where the latter overrides the former).
• Enabled plugins should be listable in --help as normal subcommands.
• CLI plguins could be either jbang commands/aliases or binaries.

A working first attempt: https://github.com/iocanel/quarkus/tree/cli-extensions

[iocanel]

Resolved by: #31198