I actually have a theory how that came about. All classes that use argparse4j are situated in the tools and connect projects, which doesn't have a dependency on core. But that's where all the CommandLine stuff that uses joptsimple is located. So to gain access to that (not joptsimple itself, but all the helper classes) would have meant adding a dependency on core to those - that may have triggered the search for something else that ended up with argparse4j.
Not sure if that was what happened, but so far its the only reason I could come up with. On Wed, Apr 17, 2019 at 5:55 PM Guozhang Wang <wangg...@gmail.com> 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 > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
