Named parameters and command line apps?

[Kevin Burton]

It seems like one way to handle command line parameters could be to do named injection.

So you would annotate with a name something like --foo 

And then you would just modify your bindings to inject that parameter but get the value from the command line arguments.

But that would be very simple command line handling.  It wouldn't support complex command line apps.

Then there are systems like Airline:

https://github.com/airlift/airline

... so it seems maybe a combination of the two would make a great way to build command line applications.

You would get dependency injection, and get command line argument handling.

How have other people handled this?  I'd rather not re-invent the wheel here if there's a "best practice" way of doing this.

[Cédric Beust ♔]

I'm not sure dependency injection is a good match for command line parsing: because such parsing is dynamic, you'd basically have providers for everything, while DI is usually better suited for configuration with values that are known at build time, or at least, very early in the life cycle of the app.

Other than that, obviously, for command line parsing, I use http://jcommander.org ;)

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/4c2fbd69-46d9-4c5b-b253-b19bef882214%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nate Bauernfeind]

I've found that things that tend to run from command-line arguments tend to not warrant Guice, and things that use Guice tend to warrant a configuration file. I've come to really appreciate's Dropwizard's approach which uses YML to configure and jackson to parse that into a POJO. I also tend to have separate configurations per guice module so that I can still get a plug-and-play feeling when I need to share modules across applications. So it's common for each of my guice modules to require a configuration object. I try to directly use the configuration in @Provides annotated methods only; I always feel dirty when I have to inject the configuration object for that module into a service.

Nate

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAOphgJBkOftxJ-JWvQQ1JsDkf45Lh9PzY5S6nbddAsgyRQHnrQ%40mail.gmail.com.

[Kevin Burton]

Cool.. jcommander doesn't look that bad.  Similar to airline... wonder which one is best.. :-P

[Christian Gruber]

https://github.com/israfil/jcommander-inject also does some module/binding work for you (and a dagger version is also planned, but the guice version works today, or did last I used it).  Point is - you can use JCommander and guice with little boilerplate. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/0cf0ce89-bbf0-42ee-a230-c9c981e21145%40googlegroups.com.

[Tim Boudreau]

I support that in Giulius:

http://timboudreau.com/builds/job/mastfrog-parent/lastSuccessfulBuild/artifact/giulius-modules/giulius-parent/giulius-settings/target/apidocs/com/mastfrog/settings/SettingsBuilder.html#parseCommandLineArguments(java.lang.String...)

public static void main(String... args) {

    // read /etc/etcFileName.properties, ~/etcFileName.properties, ./etcFileName.properties and override with 

    // command-line args

    Settings settings = new SettingsBuilder("etcFileName").addDefaultLocations().parseCommandLineArguments(args);

    // Build the injector, binding all settings (string key/value pairs) to @Named

    Dependencies deps = Dependencies.builder().add(new MyModule()).add(settings, Namespace.DEFAULT).build();

    deps.getInstance(Whatever.class);

}

See http://timboudreau.com/builds for how to include it in a Maven project;  code here: https://github.com/timboudreau/giulius

-Tim