anchor.diff:  BQCoreModule.extend(binder).addConfig("classpath:com/foo/default.yml");
   ----
   +
  -A primary motivation for this style is to provide application default configuration, with YAML files often embedded in the app and read from the classpath (as suggested by the "classpath:.." URL in the example). More then one configuration can be contributed. E.g. individual modules might load their own defaults. Multiple configs are combined in a single config tree by the runtime. The order in which this combination happens is undefined, so make sure there are no conflicts between them. If there are, consider replacing multiple conflicting configs with a single config.
  -
  -* Conditionally contributing a config file via DI. It is possible to make DI configuration inclusion conditional on the presence of a certain command line option:
  +A primary motivation for this style is to provide application default configuration, with YAML files often embedded in
  +the app and read from the classpath (as suggested by the "classpath:.." URL in the example). More then one configuration
  +can be contributed. E.g. individual modules might load their own defaults. Multiple configs are combined in a single
  +config tree by the runtime. The order in which this combination happens is undefined, so make sure there are no conflicts
  +between them. If there are, consider replacing multiple conflicting configs with a single config.
  +
  +* Conditionally contributing a config file via DI. It is possible to make DI configuration inclusion conditional on the
  +presence of a certain command line option:
   +
   [source,java]
   ----
  
positive.code: }
  ----
  
  The factory contains configuration property declarations, as well as public setters for these properties (You can create getters as well. It is not strictly required, but may be useful for unit tests, etc.). Now let's take a look at the Module class:
  
  [source,java]
  ----
  public class MyModule extends ConfigModule {
      @Provides
      public MyService createMyService(
               ConfigurationFactory configFactory,
               SomeOtherService soService) {
  
          return configFactory
                   .config(MyFactory.class, configPrefix)
                   .createMyService(soService);
      }
  }
  ----
  
  And now a sample configuration that will work with our module:
  
  [source,yaml]
  ----
  
negative.code: 
  A few points to note here:
  
  * Subclassing from `ConfigModule` is optional. `ConfigModule` provides a few utilities, such as a shorter "config"
  method and a default configuration key ("my" in this case. See the next bullet).
  * Calling our module "MyModule" and extending from `ConfigModule` gives it access to the protected "configPrefix"
  property that is initialized to the value of "my" based on the module class name. The naming convention here is to use
  the Module simple class name without the "Module" suffix and converted to lowercase.
  * `@Provides` annotation is a Guice way of marking a Module method as a "provider" for a certain type of injectable
  service. All its parameters are themselves injectable objects.
  * `ConfigurationFactory` is the class used to bind a subtree of the app YAML configuration to a given Java object
  (in our case - MyFactory). The structure of MyFactory is very simple here, but it can be as complex as needed,
  containing nested objects, arrays, maps, etc. Internally Bootique uses
  https://github.com/FasterXML/jackson[Jackson framework] to bind YAML to a Java class, so all the features of Jackson
  can be used to craft configuration.
  
  ==== Configuration File Loading
  
  A config file can be passed to a Bootique app via DI (those are usually coming from classpath) or on the command line:
  
  * Contributing a config file via DI:
  +
  