There are several reasons to consider updating, foremost in my mind is the changes coming as part of CRA in Europe. IANAL, but I don't think that non-maintained code will meet the CRA requirements, nor will code maintained by a single individual.
Our best approach may be to try to get picocli merged into commons-cli (I have done a fair amount of work on commons-cli recently and would be willing to assist in this effort) or get picocli under the ASF umbrella, assuming that Remko wants to do either of these things. I believe that subcommands would be a welcome addition to commons-cli. An annotation processor likewise may also be welcomed. Claude On Tue, Jul 16, 2024 at 10:14 AM Aleksey Yeshchenko <alek...@apple.com> wrote: > Hi Maxim, > > I think I’m not fully sold on the need to do anything at all here. The > library may no longer be maintained, but so what if it isn’t, really? > > Parsing command line arguments is a pretty well defined problem, it’s not > the kind of code that rots and needs to be updated to stay operational. If > it works now it will keep working. > > Why would we have to update it sooner or later? > > I might be missing something, of course, but what are our pain points with > airlift/airline in its current state? > > — > AY > > > On 16 Jul 2024, at 02:07, Remko Popma <rpo...@apache.org> wrote: > > > > Hi Maxim, thank you for letting me know of this discussion. > > > > Hello everyone, > > > > I developed and maintain picocli; let me try to address the concerns > raised below. > > > > For background, I am on the PMC for Apache Logging Services (mostly > involved with Log4j), and on the PMC for Apache Groovy. > > My involvement in these projects is why I chose the Apache 2.0 license. > Apache is close to my heart and I have no intention to switch to another > license. > > > > The picocli documentation mentions it is possible to incorporate picocli > in one’s project by copying a single source file. This is not meant as a > recommendation (I should probably clarify this in the docs). Some > people/projects have resistance to using an external dependency for command > line parsing and I thought this would alleviate that concern and make it > easier for picocli to gain more adoption. > > If you were to select picocli for Cassandra, I would recommend adding it > as an external dependency via Maven or Gradle. > > > > I hope this is useful. > > > > Warmly, > > Remko Popma > > > > > > > > On 2024/07/15 18:53:47 Maxim Muzafarov wrote: > >> Hello everyone, > >> > >> > >> I want to continue the discussion that was originally started here > >> [2], however, it's better to move it to a new thread with an > >> appropriate title, so that everyone is aware of the replacement > >> library we're trying to agree on. > >> > >> The question is: > >> Does everyone agree with using Picocli as an airlift/airline > >> replacement for our cli tools? > >> The prototype to look at is here [1]. > >> > >> > >> The reasons are as follows: > >> > >> Why to replace? > >> > >> There are several cli tools that rely on the airlift/airline library > >> to mark up the commands: NodeTool, JMXTool, FullQueryLogTool, > >> CompactionStress (with the size of the NodeTool dominating the rest of > >> the tools). The airline is no longer maintained, so we will have to > >> update it sooner or later anyway. > >> > >> > >> What criteria? > >> > >> Before we dive into the pros and cons of each candidate, I think we > >> have to formulate criteria for the libraries we are considering, based > >> on what we already have in the source code (from Cassandra's > >> perspective). This in itself limits the libraries we can consider. > >> > >> Criteria can be as follows: > >> - Library licensing, including risks that it may change in the future > >> (the asf libs are the safest for us from this perspective); > >> - Similarity of library design (to the airline). This means that the > >> closer the libraries are, the easier it is to migrate to them, and the > >> easier it is to get guarantees that we haven't broken anything. The > >> further away the libraries are, the more extra code and testing we > >> need; > >> - Backward compatibility. The ideal case is where the user doesn't > >> even notice that a different library is being used under the hood. > >> This includes both the help output and command output. > >> > >> Of course, all libraries need to be known and well-maintained. > >> > >> What candidates? > >> > >> > >> Picocli > >> https://picocli.info/ > >> > >> This is the well-known cli library under the Apache 2.0 license, which > >> is similar to what we have in source code right now. This also means > >> that the amount of changes (despite the number of the commands) > >> required to migrate what we have is quite small. > >> In particular, I would like to point out that: > >> - It allows us to unbind the jmx-specific command options from the > >> commands themselves, so that they can be reused in other APIs (my > >> goal); > >> - We can customize the help output so that the user doesn't notice > >> anything while using of the nodetool; > >> - The cli parser is the same as what we now do with cli arguments. > >> > >> This makes the library a good candidate, but leaves open the question > >> of changing the license of the lib in the future. However, these risks > >> are relatively small because the CLI library is not a monetizable > >> thing, as I believe. We can also mitigate the risks copying the lib to > >> sources, as it mentioned here: > >> https://picocli.info/#_getting_started > >> > >> > >> commons-cli > >> https://commons.apache.org/proper/commons-cli/ > >> > >> In terms of licenses, it is the easiest candidate for us to use as > >> it's under the asf, and in fact the library is already used in e.g. > >> BulkLoader, SSTableExpoert. > >> However, I'd like to point out the following disadvantages the library > >> has for our case: > >> - This is not a drop-in replacement for the airline commands, as the > >> lib does not have annotation for markup commands. We have to flesh out > >> all the options we have as java classes, or create our owns; > >> - Subcommands have to be supported manually, which requires extra > >> effort to adopt the cli parser (correct me if I'm wrong here). We have > >> at least several subcommands in the NodeTool e.g. cms describe, cms > >> snapshot; > >> - Apart from parsing the cli arguments, we need to manually initialize > >> the command class and set the input arguments we have. > >> > >> > >> JComannder > >> https://jcommander.org/ > >> > >> The library is licensed under the Apache 2.0 license, so the situation > >> is the same as for Picocli. Here I'd like to point out a few things I > >> encountered while prototyping: > >> - Unbinding the jmx-specific options from commands is quite tricky and > >> requires touching an internal API (which I won't do). Option > >> inheritance is not the way to go if we want to have a clear command > >> hierarchy regardless of the API used. > >> - We won't be able to inject a Logger (the Output class in terms of > >> NodeTool) or other abstractions (e.g. MBeans) directly into the > >> commands, because it doesn't support dependency injection. This is > >> also part of the activity of reusing the commands in other APIs, for > >> instance to execute them via CQL; > >> > >> More basic in comparison to the Picocli, focusing primarily on simple > >> annotation-based parsing and subcommands, and won't allow us to reuse > >> the commands outside of the cli. > >> > >> > >> airline2 > >> https://github.com/rvesse/airline > >> > >> The library is licensed under the Apache 2.0 license, and this is an > >> attempt to rebuild the original airline library. Currently, this is > >> not a drop-in replacement, as it has some minor API differences from > >> the original library. It is also not a better choice for us, as it has > >> the same drawbacks I mentioned for the previous alternatives, e.g. not > >> possible to unbind the specific options from the command and use them > >> only when commands are called from the cli. > >> > >> > >> > >> > >> [1] https://github.com/apache/cassandra/pull/2497/files > >> [2] https://lists.apache.org/thread/m9wfb3gdo9s210824c9rm2ojc9qv9412 > >> > >
