CLI module?

[steve christensen]

Any strong opinions  / requirements for a GWizard module that'd help compose CLI parsing for multiple modules?

Tons of options.... 

• Argparse4j http://argparse4j.sourceforge.net/ (this is Dropwizard's choice)
• args4j http://args4j.kohsuke.org/
• JewelCli https://github.com/lexicalscope/jewelcli
• JCommander http://jcommander.org/

-Steve

[Jeff Schnitzer]

I don't have many thoughts on the matter. I've not yet found a case for cmdline arguments in serverside apps that are not satisfied by some combination of config file + system properties. I don't understand the rationale for DW's cli processing - which doesn't mean there isn't one, of course. Do you have some insight here?

Jeff

--
You received this message because you are subscribed to the Google Groups "GWizard Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwizard+u...@googlegroups.com.
To post to this group, send email to gwi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gwizard/c967a25c-6aaa-4123-bc26-796715eae26a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[steve christensen]

I picked CLI at random out of a "what could I add to gwizard?" brainstorm. But, the more I thought about it... the less solid my use-case was. 

In dropwizard's case... They support adding subcommands. For instance, you might run your server like:

java -jar myapp.jar server cfg.yml

there's a check subcommand that will run validation against the config, but not start your server

java -jar myapp.jar check cfg.yml

(and, you can't disable server or check. or easily extend those commands either... it was a pain.)

If you include the dropwizard-migrations bundle (https://dropwizard.github.io/dropwizard/manual/migrations.html), it'll add a bunch more database migration commands (tag, migrate, dump, rollback, test, etc) 

In my dropwizard-based project... We want to supply Guice Override Modules on the command-line. For example... we expose a bunch of data over JMX, and consume data from other services' REST endpoints. During Fitnesse tests, or manual dev testing, it's nice to be able to override the HTTP client binding so that rather than actually trying to hit those external services' REST endpoints, the HTTP GET responses can just be JSON from a config file.

Anyway... Right now, in my app's main() I pick apart the JVM CLI arguments between the ones for my app vs. the ones I'll pass along to Dropwizard. Seemed like the least awful option at the time. But it's fragile and ugly

[Jeff Schnitzer]

Cool. Yeah, DW's cli stuff just doesn't scratch my particular itch.

I would hate to add things to gwizard that don't have a clear use case for someone working with the code. It's too easy to end up putting in features that are hard to use or don't really meet people's needs. I would say - if you need some cmdline tooling and you find a pattern that you really like, then let's consider adding it to gwizard. In the mean time I'm happy to leave out features that exist in other projects like DW.

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/gwizard/b7367745-f4d7-41a2-a29d-797299f8dd02%40googlegroups.com.

[steve christensen]

Very true. With the current state of GWizard, it's much clearer how an application can handle its own CLI parsing and launch behavior. And, for those with strong opinions regarding CLI parsing libraries, they can make that choice for themselves.