I do not think it is completely fair to say that it is maintained by a single individual. Looking into the commit history, the author of Picocli is accepting patches from other contributors as well. Also, I think this library is so broadly used that it is not going anywhere even if the original author stepped down from the project.
That project consists of, literally, one Java file (maybe two but AFAIK that is optional) so at worst we might just include it into the Cassandra project and maintain it ourselves in a very improbable scenario of nobody else taking over. BTW good points, Claude, about the requirements. While I am a fan of Picocli as I am using it a lot in the projects and I like its simplicity etc., I would like to mention that it would be nice if we stayed in "Apache universe" and tried to use the projects Apache delivers. It is interesting to see that we are contemplating to use something outside of Apache when there is a project dedicated for that already, it just does not meet our criteria completely. I appreciate and recognize that Maxim spent a lot of time with Picocli integration but it would be interesting to see how big gaps commons-cli has and if we could integrate with that instead. If the integration is just too much work to deliver (complex, time-consuming ...) then I would go with Picocli instead. Anyway, I am not sure what is the policy of Apache about this - if we should try to integrate with other Apache projects themselves in the first place before starting to consider other options outside of its umbrella. On Tue, Jul 16, 2024 at 11:55 AM Claude Warren, Jr via dev < dev@cassandra.apache.org> wrote: > 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 >> >> >> >>
