I've written a few dozen tools over the years and have been happy with
JCommander.  Picocli looks to follow pretty much all the same conventions,
but has a few nicer features on top.  I'd love to see the entire project
standardize on it.

On Tue, May 20, 2025 at 2:29 AM Štefan Miklošovič <smikloso...@apache.org>
wrote:

> Hey,
>
> I mapped what command line parser styles we use across the project while
> dealing with some ticket (20448) and it is mixed like this, I am talking
> about stuff we use in commons-cli for Gnu and Posix parsers:
>
> GnuParser
>
> StandaloneSplitter
> BulkLoader (aka sstableloader)
> HashPassword
> GenerateTokens
> AuditLogViewer
> StandaloneVerifier
> StandaloneSSTableUtil
> StandaloneUpgrader
> StandaloneScrubber
>
> PosixParser
>
> SSTablePartitions
> SSTableMetadataViewer
> SSTableExport
> AbstractJMXClient which is not used anywhere, huh?
>
> For these we use manual parsing of arguments without any library
>
> SSTableRepairedAtSetter
> SSTableOfflineRelevel
> SSTableLevelResetter
> SSTableExpiredBlockers
> TransformClusterMetadataHelper
>
> airline / (will be picocli-ed soon)
>
> JMXTool
> FullQueryLogTool
> CompactionStress
>
> nodetool - will be picocli-ed
>
> Stress - totally custom stuff but cassandra-easy-stress just landed now
> which uses "com.beust.jcommander"
>
> For what we have in tools, what should I base it on going forward?
>
> As a curiosity / interestingly enough, from the perspective of common-cli
> implementation, both GnuParser as well as PosixParser are marked as
> deprecated. What is not deprecated in commons-cli is "DefaultParser" which
> can be configured to mimic either style (gnu / posix).
>
> What is the official policy we have around arguments parsing? What kind of
> style should we default to for tools? Posix or Gnu? (not talking about
> nodetool as that is a category in itself).
>
> It seems like GnuParser is more prevalent, so is that one the winner here?
>
> I understand that there is a ton of legacy and we can not just change the
> styles easily for the code already there without a big bang. What I am
> trying to do here is to just know what we will go with. I do not think that
> mixing two styles arbitrarily is good.
>
> Regards
>

Reply via email to