If we are going to standardize on one argument parsing library, it should certainly be argparse4j, I think. argparse4j is simply a better argument parsing library with support for more features. One example is mutually exclusive options. argparse4j supports this with MutuallyExclusiveGroup. jopt doesn't support this, so when it is needed, we have to add extra code to manually check that mutually exclusive options are not set.
argparse4j also has subcommands. If you want something like "git add" with some set of flags, and "git remove" with another, you can do this with argparse4j, but not with jopt. This would be very helpful for clearing up confusion in a lot of our shell scripts which have accumulated dozens of arguments, most of which are only relevant to a very specific operation. But you just can't do it with jopt. Just to give an example, argparse4j with subcommands would allow you to run something like ./kafka-topics.sh list --help and get just options that were relevant for listing topics, not the full dozens of options that might relate to adding topics, removing them, etc. To be honest, though, what would help users the most is standardizing the option flags across tools. We should have a standard way of specifying bootstrap brokers, for example. (We can continue to support the old synonyms for a while, of course.) best, Colin On Wed, Apr 17, 2019, at 08:56, Guozhang Wang wrote: > I took another look at the PR itself and I think it would be great to have > this cleanup too -- I cannot remember at the beginning why we gradually > moved to different mechanism (argparse4j) for different cmds, if there's no > rationales behind it we should just make them consistent. > > Thanks for driving this! > > Guozhang > > On Wed, Apr 17, 2019 at 7:19 AM Ryanne Dolan <ryannedo...@gmail.com> wrote: > > > Sönke, I'd find this very helpful. It's annoying to keep track of which > > commands use which form -- I always seem to guess wrong. > > > > Though I don't think there is any reason to deprecate existing forms, e.g. > > consumer.config vs consumer-config. I think it's perfectly reasonable to > > have multiple spellings of the same arguments. I don't really see a > > downside to keeping the aliases around indefinitely. > > > > Ryanne > > > > > > > > > > On Wed, Apr 17, 2019, 7:07 AM Sönke Liebau > > <soenke.lie...@opencore.com.invalid> wrote: > > > > > Hi everybody, > > > > > > Jason and I were recently discussing command line argument parsing on > > > KAFKA-8131 (or rather the related pull request) [1]. > > > > > > Command line tools and their arguments are somewhat diverse at the > > moment. > > > Most of the tools use joptsimple for argument parsing, some newer java > > > tools use argparse4j instead and some tools use nothing at all. > > > I've looked for a reason as to why there are two libraries being used, > > but > > > couldn't really find anything. Paolo brought up the same question on the > > > mailing list a while back [7], but got no response either. > > > Does anybody know why this is the case? > > > > > > This results in no central place to add universal parameters like help > > and > > > version, as well as the help output looking different between some of the > > > tools. > > > Also, there are a number of parameters that should be renamed to adhere > > to > > > defaults. > > > > > > There have been a few discussions and initiatives around this in the > > past. > > > Just of the top of my head (and a 5 minute jira search) there are: > > > - KIP-14 [2] > > > - KAFKA-2111 [3] > > > - KIP-316 [4] > > > - KAFKA-1292 [5] > > > - KAFKA-3530 [6] > > > - and probably many more > > > > > > Would people generally be in favor of revisiting this topic? > > > > > > What I'd propose to do is: > > > - comb through jira and KIPs, clean up old stuff and creae a new umbrella > > > issue to track this (maybe reuse KIP-4 as well) > > > - agree on one library for parsing command line arguments (don't care > > which > > > one, but two is one too many I think) > > > - refactor tools to use one library and default way of argument parsing > > > with central help and version parameter > > > - add aliases for options that should be renamed according to KIP-4 (and > > > maybe others) so that both new and old work for a while, deprecate old > > > parameters for a cycle or two and then remove them > > > > > > I'll shut up now and see if people would consider this useful or have any > > > other input :) > > > > > > Best regards, > > > Sönke > > > > > > [1] https://github.com/apache/kafka/pull/6481#discussion_r273773003 > > > <https://issues.apache.org/jira/browse/KAFKA-8131> > > > [2] > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-14+-+Tools+Standardization > > > [3] https://issues.apache.org/jira/browse/KAFKA-2111 > > > [4] > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-316%3A+Command-line+overrides+for+ConnectDistributed+worker+properties > > > [5] https://issues.apache.org/jira/browse/KAFKA-1292 > > > [6] https://issues.apache.org/jira/browse/KAFKA-3530 > > > [7] > > > > > > > > https://sematext.com/opensee/m/Kafka/uyzND10ObP01p77VS?subj=From+Scala+to+Java+based+tools+joptsimple+vs+argparse4j > > > > > > > > -- > -- Guozhang >
