(Answering this as a cassandra person, don’t confuse this reply as board/foundation guidance)
The legal landscape is rapidly evolving with the CRA. The answer may change in the future, but I think “we have a dependency we ship that’s user-accessible and known to be abandoned” is an unhappy state that’s indefensible if there’s ever a transitive dependency issue (e.g. log4j style “oh who would have guessed that was possible” ). I’d look at this slightly differently - if someone proposed adding this library right now, we’d all say no because it’s unmaintained. That alone should be enough justification to fix the obvious problem - if it’s unmaintained, let’s remove it before we’re doing it on fire. > On Jul 16, 2024, at 8:11 AM, Ariel Weisberg <ar...@weisberg.ws> wrote: > > Hi, > > I am pretty torn down the middle on this one. Unmaintained bad, but also > Aleksey is right. If there are few/no dependencies in airline then it could > be "done" given the narrow scope of what it does. > > It seems to depend on Guava, javax.inject, and findbugs. Seems like we can > probably update the dependencies on our end if there is a security issue. > > Can we get clarity from Apache legal on whether simply being unmaintained > will be something we are motivated to fix for legal reasons? > > If we have the code/prototype now (assuming we settle on Picocli), is the > counter argument "churn bad" as strong? I don't anticipate changing from one > to the other being too bad if someone else is footing the bill so to speak. > Especially if Maxim is willing to take the lead on any bugs that we might > uncover in the switch. > > Ariel > > On Mon, Jul 15, 2024, at 2:53 PM, 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
