[ https://issues.jboss.org/browse/WFCORE-2038?page=com.atlassian.jira.plugi... ] 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). -- This message was sent by Atlassian JIRA (v7.2.3#72005)