Reconsider use of args4j for command line argument parsing

[eevans]

The CLI component currently uses args4j to parse command line arguments. This works well for simple things, but not so well for others. For example, producing useful help synopsis for sub-commands. It's also entirely possible that I just don't know what I'm doing.

Airline is one alternative that might work better, there are probably others as well.

[justinpitts]

I have successfully used jewelcli. I'd be happy to pick this one up if you like.

[eevans]

I have successfully used jewelcli. I'd be happy to pick this one up if you like.

Sure, that'd be great; Thanks!

Out of curiosity, do you know if jewelcli is still being maintained? It looks like the last commit was almost 2 years ago.

[justinpitts]

AFAIK it is not. It's pretty stable - glancing through the open issues, I don't see anything that worries me.

[eevans]

My main complaint with args4j is that it doesn't make the generation of sub-command help synopsis very easy. Some of these sub-commands have their own arguments. Ideally you'd be able to do java -jar cli.jar table-info -h, and get synopsis for the just that command (while keeping everything neatly encapsulated in the command classes), but if the args4j api supports this, I wasn't able to figure out how (admittedly I didn't spend a lot of time).

For what it's worth, Airline does support this, which is why I mentioned it (and it's what Cassandra uses, so the output would be familiar).

Does jewelcli support this? From a quick perusal, it wasn't obvious that it does (or doesn't), so apologies if this is obvious.

[justinpitts]

No apology necessary.

My understanding so far is that a subcommand in Airline is a Group or Groups annotation. Have you tried this out? It doesn't seem to be well documented.

If I were doing this with Jewel, I'd have an enum of subcommands, a common interface with the common options for each, and a interfaces for the subcommand-specific options. I'd then use the enum to dispatch the appropriate factory/parse. This approach would directly support sub-command help.

So: Airline seems to support it, but lacks documentation. It's not directly supported but achievable with jewel.

Totally up to you.

[eevans]

My understanding so far is that a subcommand in Airline is a Group or Groups annotation. Have you tried this out? It doesn't seem to be well documented.

Not personally, but this is how nodetool works in Cassandra. See for example https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/TableHistograms.java.

Push come to shove, I was just going to cargo-cult a working example.

If I were doing this with Jewel, I'd have an enum of subcommands, a common interface with the common options for each, and a interfaces for the subcommand-specific options. I'd then use the enum to dispatch the appropriate factory/parse. This approach would directly support sub-command help.

So: Airline seems to support it, but lacks documentation. It's not directly supported but achievable with jewel.

Totally up to you.

Like most programmers, I am capable of forming very strong opinions on almost anything (regardless of how trivial), but I try to pump the brakes on that pretty hard when someone else is offering to do the work. :)

[justinpitts]

Looking at the NodeTool class itself, I'm not sure I see a huge difference between what I said jewel would need to support it and Airline.

I try to pump the brakes on that pretty hard when someone else is offering to do the work. :)

Appreciated greatly, but it is your project.

[justinpitts]

I'll put something together. I'll try airline first, because, if Cassandra devs want to work on creole, it'll be lower friction. I may even do a pull request for each, if I feel Airline comes out icky.