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 On Thu, Oct 9, 2014 at 10:05 PM, Cédric Beust ♔ <[email protected]> wrote: > 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 > > > On Thu, Oct 9, 2014 at 6:17 PM, Kevin Burton <[email protected]> wrote: > >> 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. >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 >> <https://groups.google.com/d/msgid/google-guice/4c2fbd69-46d9-4c5b-b253-b19bef882214%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/CAOphgJBkOftxJ-JWvQQ1JsDkf45Lh9PzY5S6nbddAsgyRQHnrQ%40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CAOphgJBkOftxJ-JWvQQ1JsDkf45Lh9PzY5S6nbddAsgyRQHnrQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAHNex9_TKi%3D49FvN1m_%3Dwmz35WKgO3_FKjqMW-xNqgam_Nbeew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
