+1 on the feature branch allowing breaking the effort into smaller chunks that can be even worked in parallel.
> On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič <smikloso...@apache.org> wrote: > > Hi Maxim, > > thank you for doing this. I think that Picocli is a great choice, comparing > it with airline v2 which is an attempt to resurrect the original airline, it > seems to be way more active and popular. > > I personally don't have anything against what you suggested, however I think > that this kind of work will put additional stress on us being sure that the > output of the commands will be exactly as it is now. We do have nodetool > tests which are covering the tests for the output which is very handy in this > kind of situation, but I think we do not test all of them. It would be great > to increase our test coverage where possible in this area and I think it is > actually going to be a requirement as only then we will be sure that old and > new code produces the same output. > > I think it is too soon to contemplate when we switch to this, we just need to > be sure that it is the same so existing integrations will not be broken. > > Regards > > On Fri, Jun 28, 2024 at 3:48 PM Maxim Muzafarov <mmu...@apache.org > <mailto:mmu...@apache.org>> wrote: >> Hello everyone, >> >> >> The nodetool relies on the airlift/airline library to mark up the CLI >> commands used to manage Cassandra, which are part of our public API. >> This library is no longer maintained, so we need to update it anyway, >> and the good news is that we already have several good alternatives: >> airline-2 [3] or picocli [2]. >> >> In this message, I'm mainly talking about CASSANDRA-17445 [4], which >> refers to the problem and is a prerequisite for a larger CEP-38 CQL >> Management API [5]. It doesn't make sense to use annotations from the >> deprecated library to build a new API, so this is another reason to >> update the library as soon as possible and do some inherently small >> code refactoring required for the CEP-38. >> >> In addition to being widely used and well supported, the Picocli >> library offers the following advantages for us: >> - We can detach the jmx-specific parameters from the commands so that >> they can be reused in other APIs (e.g. without host, port) while >> remaining backwards compatible; >> - We can set up nodetool's autocompletion after the migration with >> minimal effort; >> - There is a good Picocli ecosystem of tools that we can use to >> simplify our codebase, e.g. generate man pages tool to make our CLIs >> more Unix friendly [7]; >> >> >> = Prototype = >> >> I have a working prototype [8] that shows what the result will look >> like. The prototype includes: >> - Tests between the execution of commands via the nodetool and nodtoolv2; >> - 5 out of 164 nodetool commands have been moved so far, to show the >> refactoring we need to do to the command's body; >> - The command help output under for the nodetoolv2 is the same as it >> is currently for the nodetool and this is the default, however a >> "cassandra.cli.picocli.layout" is added to switch to the Picocli >> defaults; >> - You can also see that the colour scheme is applied by the Picocli >> out of the box, and this is how it looks [9]; >> - The nodetoolv2 is called first when the shell is triggered, and if >> the nodetoolv2 doesn't contain the command it needs yet, it falls back >> to the nodetool and the old argument parser; >> >> >> Since the number of commands is quite large (164), I'd like to create >> a feature branch and move all the commands one at a time, while >> keeping the output backwards by applying additional tests at the same >> time and checking that the CI is always green. I think the "feature >> branch" approach will be less stressful for us since it focuses on >> requiring a review of only tedious changes to the feature branch, >> rather than reviewing the 15k line patch. >> >> >> Anyway, I am open to any suggestions and advice based on your >> experience and best practices for this case. Looking forward to your >> thoughts and suggestions. >> >> >> >> [1] https://github.com/airlift/airline >> [2] https://picocli.info/ >> [3] https://github.com/rvesse/airline >> [4] https://issues.apache.org/jira/browse/CASSANDRA-17445 >> [5] >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API >> [6] >> https://github.com/apache/cassandra/pull/2497/files#diff-acdd5f29d28df5c02f4bfc933528f084508b4923112e312e68a4aff7df973bce >> [7] https://picocli.info/man/gen-manpage.html >> [8] https://github.com/apache/cassandra/pull/2497/files >> [9] >> https://github.com/apache/cassandra/assets/3415046/57b14ae0-ff59-43d2-b542-10d3218ae075
