The motivation of moving CLI to a different Aesh API is to take benefit of latest Aesh features:

• No more active polling, low level Layer in sync with CLI.
• Better completion (e.g.: in the middle of the command). Completions can be easily reused by different commands.
• Modern/Descriptive Command API that scales with command complexity. Simple API for simple use cases.
• Automatic test generation. Reflection on Command classes would allow to test part of commands automaticaly.
• Help generation. Reflection on Command classes would allow to generate help content.
• Command top level parsing (command/action/options) is handled by Aesh. (NB: Complex parsing: Value and Operation syntax is still implemented by the CLI).
• Should simplify the work for creating new commands by customers, community and within Red Hat.
• Support for piping and redirecting to other commands.
• Easily take advantage of utility commands that Aesh provides through the aesh-extensions module. Like less, more, grep, man, etc.

In Addition this is an opportunity to revisit the exposed commands and possibly offer a better user experience (but we must keep backward compatibility at the command level).

Aesh Command API example

@CommandDefinition(name = "mycommand", description = "Do some stuff")

public class MyCommand implements <CliCommandInvocation> {

    @Option(hasvalue = false)

    private boolean myoption;

     @Override

     public CommandResult execute(CliCommandInvocation commandInvocation) {

         if (myoption) {

               ModelControllerClient client = commandInvocation.getCommandContext().getModelControllerClient();

               // Access to server, implement command logic

               // ...

         }      

     }

}

CLI backward compatibility

2 aspects:

1. Command line, must be 100% backward compatible. Legacy syntax is hidden from completion but is usable. We are thinking at offering a "legacy" mode where completion would be active.
   
2. CommandHandler API should be deprecated, ServiceLoader discovered CommandHandler should still be usable.

Actual implementation

The work is done in the following branch (in sync with wildly-core master):GitHub - jfdenise/wildfly-core at aesh

Revamped CLI commands specification

Common rules for Command:

• Command should be as auto-descriptive as possible, no need to read help. Completion should be enough to drive you do your task.
• Keep the set of options simple.
• One use case should map to one (at most) action.
• Create less command, more sub commands. Grouping actions under a single command helps figure-out CLI capabilities. Each command with its own set of options.
• No disjunctive set of options, prefer action per group of options.
• Try to avoid "this option makes sense only if this other one is not used".
• If an option is exposed, it must be usable, no "This command can't be run in XXX mode".
• Homogeneous option naming (that is already the case)
• For Command that have actions, no implicit action should be offered. This means that the top level command should not offer any feature other than help.
• Backward compatibility options mustn't pollute completion.
• Help option should be hidden but supported.
• All command has an help that only describe it and provide a reference to sub commands help.
• Each sub command has its own help. This will provide scalable help.
  • Aesh have a builtin man command that can be useful for static commands where we can write a doc file (atm it must be packaged into the jboss-cli.jar ).
  • Combination of static content and content retrieved from the Option/Command descriptions should be offered.

This table contains the specification of each core commands. The rows in bold are commands that need rework to comply with the command rules.

Some domain specific options are not exposed but must be supported as they are today.

NB: All discovered commands (patch, ...) should work as of today. Marked deprecated they should be rewrote in the longer term.