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 >
