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

[Marek Kopecký (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopecký updated WFCORE-2038:
----------------------------------
    Description: 
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).



  was:
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).





> 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)