anchor.diff:  
   If in your Module you are planning to redefine any services from the upstream modules, specify those upstream modules in the `overrides()` collection. In practice overrides are rarely needed, and often can be replaced with service decomposition.
   
  -=== Chapter 7. Configuration and Configurable Factories
  +=== Configuration and Configurable Factories
   
   Bootique Modules obtain their configuration in a form of "factory objects". We'll show some examples shortly. For now let's focus on the big picture, namely the fact that Bootique app configuration is multi-layered and roughly follows the sequence of "code - config files (contributed) - config files (CLI) - overrides". "Code" is the default values that are provided in constructors of factory objects. Config files overlay those defaults with their own values. Config files can be either contributed in the code, or specified on the command line. Files is where the bulk of configuration usually stored. Finally config values may be further overridden via Java properties and/or environment variables.
   
  
positive.code: 
  There are other flavors of bindings in Guice. Please refer to https://github.com/google/guice/wiki/Motivation[Guice documentation] for details. One important form extensively used in Bootique is https://github.com/google/guice/wiki/Multibindings[Multibinding].
  
  === Chapter 6. Modules Auto-Loading
  
  Modules can be automatically loaded via `Bootique.autoLoadModules()` as long as they are included in your aplication dependencies. Auto-loading depends on the Java https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html[ServiceLoader mechanism]. To ensure your modules can be auto-loaded do two things. First implement `io.bootique.BQModuleProvider` interface specific to your module:
  
  
negative.code: 
  Based on the specified policy Bootique figures out the sequence of execution and runs the main and the secondary commands.
  
  === Options
  
  ==== Simple Options
  
  