anchor.diff:  
   `java` plugins rely on the http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html[`maven-bundle-plugin`] to produce the correct OSGI plugin (with the correct `MANIFEST.MF`). It is recommened to start from a plugin that already works, as the build configuration can be quite tricky. A good example is to look at the `pom.xml` from the https://github.com/killbill/killbill-hello-world-java-plugin/blob/master/pom.xml[hello world plugin]
   
  -The build will produce a `jar` under the `target` directory and this should contain all the classes and configuration files directly accessible for that plugin. OSGI also provides a way to import classes that are exported by other plugins and this is configured in the `Import-Package` section of the `maven-bundle-plugin`. The hello world plugin provides some default based on the https://github.com/killbill/killbill-platform/blob/killbill-platform-0.22/osgi/src/main/java/org/killbill/billing/osgi/config/OSGIConfig.java#L49[classes exported by the system bundle in Kill Bill]. Note that Kill Bill offers a system property, `org.killbill.osgi.system.bundle.export.packages.extra`, to add additional packages exported and that could in turn be imported by the plugin. 
  +The build will produce a `jar` under the `target` directory and this should contain all the classes and configuration files directly accessible for that plugin. OSGI also provides a way to import classes that are exported by other plugins and this is configured in the `Import-Package` section of the `maven-bundle-plugin`. The hello world plugin provides some default based on the https://github.com/killbill/killbill-platform/blob/killbill-platform-0.22/osgi/src/main/java/org/killbill/billing/osgi/config/OSGIConfig.java#L49[classes exported by the system bundle in Kill Bill]. Kill Bill offers a system property, `org.killbill.osgi.system.bundle.export.packages.extra`, to specify additional packages to be exported by the system bundle and that could in turn be imported by the plugin. Desiging which packages are served by the plugin jar and which one are imported from other bundle (and mostly the system bundle inside Kill Bill) is one of the challenge of the OSGI mechanism.
   
   
   == Ruby Plugins
  
positive.code: Note that if you don't need any custom configuration, make sure to delete the default YAML configuration file `/var/tmp/bundles/plugins/ruby/killbill-\*/*/*.yml`. In development mode, i.e. when you are running tests outside of Kill Bill (see `rake test:spec` and `rake test:remote:spec`), the database configuration is specified in that YAML file (payment plugins rely on a couple of database tables, principally to keep the credit card tokens and gateway-specific details for transactions, such as reference codes). By default, the plugin will use SQLite. If you uncomment the part of the YAML file below the comment "In Kill Bill", this will tell the plugin to use the JNDI connection exposed by Kill Bill instead. This is the default in case the file isn't present (or if the database section is missing).
  
  
  Also, in the case of `ruby` plugin (and as mentionned before), the correct version of the `jruby.jar` must exist (and be name that way) under the `platform` directory entry. The correct version must match the Kill Bill version (or more precisely the version of the https://github.com/killbill/killbill-platform[platform] used for the a specific version of https://github.com/killbill/killbill[killbill]).
  
  
  === Deployment Through KPM
  
negative.code: 
  Today, both our `ruby` and `java` plugins are released through maven and are therefore identified through their maven coordinates.
  We might support other schemes in the future but today this is the only way we offer to download and install publicly released plugins.
  Plugin Coordinates are a bit heavy to manipulate after the download was made, and also they don't solve the case of a non published plugins (typical use case for a plugin being developed), so we introduced some identifers.
  
  
  As mentioned earlier, Kill Bill will scan the filesystem (`org.killbill.osgi.bundle.install.dir`) on start-up to detect and then start all the plugins. The name on the filesystem (e.g in our previous example `killbill-stripe`) constitutes what we call the **`pluginName`**
  When installing using KPM, the `pluginName` is dependent on how the plugin was packaged and also differs between ruby and java. For well known publicly available Kill Bill plugins, we adopted a (sane) convention, but we have no way to enforce that convention for third party plugins.
  Also, note that we could change the name of `killbill-stripe` to `foo` on the filesystem (`mv killbill-stripe foo`) and then suddenly Kill Bill would see that plugin as being the `foo` plugin.
  Therefore, the `pluginName` is not a reliable way to identify the plugin, and is used solely by Kill Bill as an runtime identifier.
  
  The `pluginKey` is the identifier for the plugin and is used for all the user visible operations, whether through KPM command line tool or whether using the http://docs.killbill.io/0.16/plugin_management.html[Plugin Management APIs].
  There is a distinction to be made between publicly released Kill Bill plugins and third party plugins:
  
  * (Publicly Released) Kill Bill Plugins: All the plugins developed by the Kill Bill core team are maintained in a https://github.com/killbill/killbill-cloud/blob/master/kpm/lib/kpm/plugins_directory.yml[repository] (we provide today a simple file-based repository, but this may change in the future as we start accepting certified third-party plugins).
  Each entry in that repository is identified by a key, and that key is the `pluginKey`.
  * Third party plugins: For third party plugins, the key is specified at the time the plugin gets installed. The key must be of the form `<prefix>::<something>` to make sure there is no name collision with Kill Bill plugin keys.
  
  