Info: This part of the documentation aims at presenting all the available commands in CLiC (or at least the commands we know about). If you want to learn about how to develop your own commands, please have a look at this documentation.



This command is provided out of the box with CLiC framework and allows to get information about all the commands which are available in an Eclipse instance. It doesn't require any arguments, so you just have to type list in order to execute it. It'll display the names and descriptions of each available commands:


Also, this command will be able to give you information about all the flows which are registered in your Eclipse instance.


This command is provided out of the box with CLiC framework and allows to get some detailed information about a particular command which is available in an Eclise instance. It requires 1 parameter, command which allows to specify the name of the command for which you need some help. So you can type something like: help --command command-name. It'll display some details about the specified command and the arguments which are needed:


Info: As you may saw from this example, it's possible to use short versions of the arguments to provide when there's no ambiguity on the arguments names, just like this -co instead of -command.

Please notice that if you don't specify any parameters for this command, and only execute help, then it'll display the help message for the command itself.


This particular CLiC command allows to deal with any execution based on Maven. It aims at letting people define easily some tasks thanks to Maven plugins or Maven pom configurations and execute them through a CLiC plugin. In the case of Maven pom configuration, the plugin will be able to generate a temporary pom.xml file allowing to use the content defined in a parent pom. For this documentation, we'll take a concrete example in order to illustrate how this plugin can used. For this example, let's take into consideration a remote shell example: a Maven executable allowing to execute a command to a remote server using ssh.

0. Creation of the Maven executable

While creating a Maven executable to be used by CLiC, we always have two different choices: creating a complete Maven plugin, which allows to implement something to do or some interactions to perform, or write some configuration of an existing Maven plugin in a pom.xml file, which is really easy to do since you don't need any particular Maven knowledge. Let's take this second alternative as our example. If you need/want to write your own Maven plugin to cover your needs, maybe you can have a look at this documentation.

In our case, and for a simple way of invoking ssh from an existing Maven plugin, we'll rely on the antrun plugin which is available for Maven, and write a simple pom.xml file:

From this simple example, you see that we can specify really easily in a pom.xml everything we want: references to our executable thanks to the groupId and artifactId, but also a version so we can take the benefits of Maven versionning. Finally, we can plug the behavior wherever we want, behind a particular goal or phase, or anything.

Please notice that in this example, we're specifying a few variables that will need to be provided during the execution in order to keep our executable generic.

1. Sharing the executable with my colleagues

Depending if you want to share your executable or not, you can install it on Nexus, thanks to a Jenkins job for example. For this, you simply need to run a mvn install command, from your local environment if you want to use/test it locally, and from Jenkins in order to install it on Nexus and share it with your coworkers.

Info: We're considering in this example that you're using the classical Jenkins/Nexus architecture in order to deal with Maven builds. Depending on your infrastructure's particularities, you may deploy to Nexus from your local environment, or use some other tools to proceed with the sharing step.

2. Invoking your executable from the command line

As soon as your executable has been installed somewhere (locally or on an accessible Nexus instance), you can invoke it easily from CLiC. For this, simply use the clic:mvn command with the following parameters:

  • --maven-reference: allowing to specify the reference of the Maven executable you defined using the syntax groupId:artifactId:version, in our case it'll be com.worldline.clic:example.remote-shell:1.0.0-SNAPSHOT,
  • --generate-pom: indicates that our Maven executable is just a configured pom.xml, so a temporary pom.xml needs to be generated locally in order to allow the execution of the plugin, (do not use this option if you want to execute directly a Maven plugin),
  • --maven-command: allows to specify the Maven command to be executed in order to reach the executable you defined, in our example, it'll be antrun:run as we're using the antrun plugin,
  • Any other parameters you'd like to send to Maven using the -Dparam=value syntax.

Based on our example, and just for the illustration (do not reproduce this behavior because of obvious security issues), we could execute our remote-shell command thanks to CLiC using this kind of command:

And here it is! You just executed a remote shell command from CLiC using a simple Maven configuration. For sure, that's not the final result of what we want to do cause the command line is still pretty hard to write, but at least, we just illustrated that deploying executables from Maven is easy... And on top of that, we take the benefits of:

  • Maven automated downloading, when an executable is missing, Maven downloads it,
  • Maven versionning, allowing to deal with SNAPSHOTs, downloading the latest version, etc.
  • Maven ecosystem, allowing to use out of the box dozens of existing plugins that just need a few configuration,
  • And many more Maven advantages, such as profiles/settings/encryption and so on, already managed by Maven engine!

3. Default and/or shared configuration

Another really nice feature that we can use from Maven is inheritance. As we're using Maven variables in order to obtain the different values we need to use, it's not mandatory for us to provide them from the command line, and we can simply create another pom.xml file, inheriting from the one we created initially in order to set up some values:

From this example, I just simply created a new pom defining a few values as properties. I can then simply install this pom locally thanks to mvn install, or share it with your colleagues thanks to a shared repository such as Nexus.

Finally, and because some values are already present in this configuration, I can invoke my Maven executable with the same type of commands, but without specifying all the default values:

Thanks to this new invokation (note that the --maven-reference has changed), I can invoke the same executable without specifying all the parameters. Moreover, if I shared this new pom.xml with some coworkers, they can invoke the same with a shared configuration! Icing on the cake, and thanks to Maven, this shared configuration is also versionned, and downloaded automatically when needed!

For more advanded usage, you can even think of using Maven profiles, Maven settings and their global parameters, etc.

4. Industrialization of Maven commands

Please note that thanks to the programmatic invocation of commands, it's possible, and really easy, to bring some industrialization while dealing with Maven commands execution. You can indeed write your own command which allows to generate a complete Maven command, and then execute it with your own parameters. Have a look at the documentation to see how to invoke commands programmatically ;)

5. Defining flows directly in Maven

On top of the flow feature which is available directly in CLiC, it's also possible to manage your flows directly from Maven. Indeed, it's possible to call various goals in the same command line, and you can also define a Maven plugin allowing to wrap different directives to be executed.

As for Maven, if you want to develop some flows that you'd like to be invoked remotely, we recommend to develop a Maven plugin managing the flow you'd like to execute by invoking sequentially the commands you'd like to run.