A plugin implements a command in one of the following ways:

• As an arbitrary executable

• As a java source file

• As a jar (with main)

• As a maven artifact

• As a JBang alias

Plugins are added to the CLI either explicitly using the Quarkus CLI, or implicitly by adding extensions to the project.

Let’s see what the CLI commands related to plugins are available:

Initially, there are no plugins installed so, quarkus plug list returns an empty list:

It also returns a hint suggesting the use of the --installable, but what are installable plugins ?

Installable refers to executables found in PATH, or JBang aliases prefixed with the quarkus prefix. Note: The command does require JBang (and prompts users for installation if not already installed).

The plugins listed are JBang aliases that are available in the quarkus.io JBang catalog (enabled by default). More catalogs can be added using the JBang binary.

Let’s see how to create a plugin for the Quarkus CLI. Out of the box the Quarkus CLI provides 3 ways of creating projects:

• A webapp

• A command line application

• A Quarkus extension

We are going to create a plugin for create that creates new applications using Quarkus Quickstarts. This is as simple as writing a script that clones the repository from Github and copies the quickstart of choice. To add some extra value on top of it let’s use a Sparse Checkout and also limit depth to 1. This minimizes the amount of data transferred and speeds things up. Moreover, recalling the actual steps needed for a Sparse Checkout is not easy, therefore it’s something that is really handy to have as a script:

Let’s save the script above in a file named quarkus-create-from-quickstart and add it to the PATH. The quarkus- is the required prefix and create is the name of the command under which the plugin is going to be installed. Next time quarkus plug list --installable is run it picks up the script:

The plugin can be now installed using:

The plugin now appears in the quarkus --help under the create command:

And it can be used as regular command. Let’s use it to create an application from the Hibernate ORM Panache Quickstart:

Using shell scripts or arbitrary binaries (written in any language) is one of writing plugins. Java developers can alternatively put their java skills to use. Any source file that contains a main or any jar that defines a main class can be used directly by passing their location (Path or URL). In case of jars maven coordinates in the form of GACTV (<Group ID>:<Artifact Id>:<Classifier>:<Type>:<Version>) are also supported.

Let’s rewrite the create-from-github in Java and see how we can plug a java source file to the Quarkus CLI. The implementation will use jgit and commons.io. To simplify dependency management the source file includes JBang meta comments that define the fore mentioned dependencies:

To add this source file as a Quarkus CLI plugin:

Note that the name derived from the actual file/class name that is using Camel Case and therefore is not matched to the create sub command. Instead, it is added as a sibling to create:

As of 3.1.2.Final there is no direct way to alias a plugin. However, aliases are supported by JBang. Here’s how aliases can be used:

In all the examples so far the plugins listed as user scoped. This means that the plugins are global to the user. It is possible however to also have project scoped plugins. This is important as it allows:

• Having project specific plugins

• Overriding versions per project

• Sharing the plugin catalog (via version control)

• Support extension provided plugins

When the quarkus plug add command is called from within a project, the plugin is added to the project catalog, unless the --user options is used. The plugin catalog is persisted in .quarkus in the root of the project. By adding this folder to version control, the project plugin catalog is shared between users of the project. In this case, its a good idea to also include the actual plugin source files in version control, or use a shared JBang catalog.

Let’s create script that allows users to setup their project in an ArgoCD developer instance. ArgoCD is a GitOps continous delivery tool for Kubernetes. The following example demonstrates its setup process can be automated as a Quarkus CLI plugin:

More specifically the plugin performs the following:

• Installs the ArgoCD binary

• Installs the ArgoCD resources to the target cluster

• It generated Kubernetes manifests for the project

• It adds the generated resources to version control

• It setups the project to ArgoCD

Even though some of the steps above need only need to be performed once (e.g. adding manifests to version control) the remaining steps have to be performed for each developer environment. So, instead of adding the script to some shared folder or repository forever to be forgotten, it makes sense to have it inside the project as a CLI plugin. The source of the script could be something like:

Let’s save the file under bin/quarkus-argocd-setup and add it as a plugin:

Now by calling quarkus argocd-setup the application is setup for use with ArgoCD.

A Quarkus extension may contribute to the CLI plugins that are available to a project. At the moment the following Quarkiverse extensions provide plugins:

Let’s see how things work when such an extension is added to a project. The following command adds the Quarkus Helm extension, along with the Kubernetes and docker extensions that often are used together.

Now the `helm plugin should be automatically added next time the CLI used:

The plugin can now be used to install the application using Helm charts. The plugin itself is a simple wrapper around the official Helm binary that simplifies its use. For example the app can be easily installed using:

The Quarkus CLI plugin system is not just a way for the Quarkus team to rightsize and modularize the Quarkus CLI, it also offers teams a way of creating scripts and recipes specific to their project and distribute them along with the code.