[jboss-jira] [JBoss JIRA] (WFCORE-2038) Update CLI to use aesh-readline 1.0

[Jean-Francois Denise (JIRA)]

Jean-Francois Denise created WFCORE-2038:
--------------------------------------------

             Summary: Update CLI to use aesh-readline 1.0
                 Key: WFCORE-2038
                 URL: https://issues.jboss.org/browse/WFCORE-2038
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


Today CLI uses aesh 0.66.+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.+ library is going to be split into 2 libraries:
1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C).
2) aesh 1.0, based on aesh-readline containing the console and the Command API.

It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite.
 So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline.

The benefits are:
- Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1%
- Less tricks in the CLI code to support prompting users (userName, password).
- Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues.
- aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline.
- aesh-readline should consume less memory and be more reactive.

The risks:
- aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass).





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)