anchor.diff:  
   == System Properties
   
  -As described previoulsy, Kill Bill plugins are started with access to system properties through the use of a special interface https://github.com/killbill/killbill-platform/blob/master/osgi-api/src/main/java/org/killbill/billing/osgi/api/OSGIConfigProperties.java[OSGIConfigProperties]. System properties passed to the JVM are then accessible to the plugins and can be used to tweak the behavior of the plugin as needed.
  +Kill Bill plugins can access Kill Bill properties through the use of a special interface https://github.com/killbill/killbill-platform/blob/master/osgi-api/src/main/java/org/killbill/billing/osgi/api/OSGIConfigProperties.java[OSGIConfigProperties]. System properties passed to the JVM and properties from the `killbill.properties` configuration file are then accessible to the plugins and can be used to tweak the behavior of the plugin as needed.
   
   == Configuration File
   
  -Property files can be used to configure global settings for a plugin. Those property files need to be part of the archive (and OSGI mechanism) will make sure these are only visible to the particular plugin:
  +Property files can be used to configure global settings for a plugin. Those property files need to be part of the archive (the OSGI mechanism will make sure these are only visible to the particular plugin):
   
   * For `java` plugins, the property file needs to be on the classpath (`resource` directory)
   * For `ruby` plugins, the property file is often located at the root of the archive
   
  -There is no restriction on the format of the propery file, but often the case, `ruby` plugins will use `yml` files and `java` plugins will rely on `key-value`, `json` or `xml` files. 
  +There is no restriction on the format of the propery file, but typically `ruby` plugins will use `yml` files and `java` plugins will rely on `key-value` properties, `json` or `xml` files. 
   
   == Per-tenant Configuration
   
  -The two previous mechanisms work well for global settings, but are inadequate to configure the plugins on a per-tenant fashion (e.g for a payment plugin interacting with a payment gateway, different credentials might be needed for different tenants). In those situations, Kill Bill provides apis to upload/retrieve/delete per-tenant plugin configurations:
  +The two previous mechanisms work well for global settings, but are inadequate to configure the plugins on a per-tenant fashion (e.g for a payment plugin interacting with a payment gateway, different credentials might be needed for different tenants). In those situations, Kill Bill provides APIs to upload/retrieve/delete per-tenant plugin configurations:
   
   ```
   # Upload new config
  
positive.code: 
  Under `platform`, we will find the following:
  
  * `jruby.jar` : the Runtime jruby jar that is loaded into killbill for each ruby plugin
  * A set of http://felix.apache.org/downloads.cgi[pure OSGI plugins] (unrelated to Kill Bill plugin) and required for things like OSGI logging, OSGI console, ...
  
  Under `java` and `ruby`, we will find one entry per plugin, and then followed by one entry per version.
  For instance, if we had installed two versions for the ruby `stripe` plugin, we would see the following (`SET_DEFAULT` is a symbolic link that point to the default active version):
  
  ```
  
negative.code: 
  === Java Plugins
  
  For `java` plugins, deploying by hand consists of building the self contained OSGI jar, and copying that jar at the right location. For example, the `adyen` plugin with a version with version `0.3.2` would show up as the following:
  
  ```
  java
  