anchor.diff:  
   == Design
   
  -ConfigProvider is the bootstrap class, which has static methods to get hold of a config object, which is the aggregated properties from multiple data sources, whether registered explicitly or  from default sources. The default config sources are:
  +A `Config` consists of the information collected from the registered `ConfigSource` instances.
  +These ConfigSources get sorted according to their _ordinal_.
  +That way it is possible to overwrite configuration with higher importance from outside.
   
  -* System properties (ordinal=400)
  -* Environment properties (ordinal=300)
  -* /META-INF/config.properties (ordinal=100)
  -* /META-INF/config.xml (ordinal=100)
  -* /META-INF/config.json (ordinal=100)
  +The current configuration of an application can be accessed via `ConfigProvider#getConfig()`.
   
  -If there is some custom config data to be configured, the config sources can be added by calling `ConfigProvider.getBuilder().withSources()`
  -
  -A `Config` consists of the information collected from the registered `javax.config.spi.ConfigSource` s.
  +A `Config` consists of the information collected from the registered `org.eclipse.microprofile.config.spi.ConfigSource` s.
   These `ConfigSource` s get sorted according to their _ordinal_.
   That way it is possible to overwrite configuration with lower importance from outside.
   
  
positive.code: 
  ## Status
  
  Config proposal!
  
  == Rational
  
  Typically, the majority of applications need to be configured based on a running environment. Frequently, configuration data needs to be stored outside an application so that applications do not need to be repackaged. The configuration data (data source) can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). If a property is defined in multiple data sources, which value should be used? Therefore, there should be a policy that orders the data sources. Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for micro services running in a cloud environment.
  
  == Implementaions
  
  
negative.code: 
  * `System.getProperties()` (ordinal=400)
  * `System.getenv()` (ordinal=300)
  * all `META-INF/java-config.properties` files on the ClassPath.
  (default ordinal=100, separately configurable via a config_ordinal property inside each file)
  
  Therefore, the default values can be specified in the above files packaged with the application and the value can be overwritten later for each deployment.
  
  == Custom ConfigSources
  
  It is possible to write and register a custom `ConfigSources`.
  An example would be a ConfigSource which gets the configured values from a shared database table in a cluster.
  
  == Building
  
  The whole MicroProfile config project can be built via Apache Maven
  
  `$> mvn clean install`
  
  