diff --git a/developers/buildsystem.md b/developers/buildsystem.md
index 93d27686c..5b43d78ca 100644
--- a/developers/buildsystem.md
+++ b/developers/buildsystem.md
@@ -19,10 +19,8 @@ This section talks about some common buildsystem related topics and also some qu
## Adding Dependencies
-Generally all dependencies should be OSGi-bundles and available on JCenter.
-
-** External dependency **
-In most cases they should be referenced in the project POM with scope `provided`:
+Generally all dependencies should be available on JCenter.
+In most cases they should be referenced in the project POM with scope `compile`:
```
@@ -30,45 +28,39 @@ In most cases they should be referenced in the project POM with scope `provided`
foo.bar
baz
1.0.0
- provided
+ compile
```
+These dependencies are embedded in the resulting bundle automatically.
+
+There are two exceptions:
+
+1) Dependencies to other openHAB bundles (e.g. `org.openhab.addons.bundles/org.openhab.binding.bluetooth/2.5.0-SNAPSHOT` or `org.openhab.addons.bundles/org.openhab.transform.map/2.5.0-SNAPSHOT`).
+2) Bundles that are used by more than one binding (e.g. Netty-bundles like `io.netty/netty-common/4.1.34.Final`).
+
+Dependencies on other openHAB bundles should have the scope `provided`.
To ensure that they are available at runtime they also need to be added to the `feature.xml`:
```
- mvn:foo.bar/baz/1.0.0
+ mvn:org.openhab.addons.bundles/org.openhab.binding.bluetooth/2.5.0-SNAPSHOT
```
-If the bundle is not an OSGi-bundle, you need to wrap it and provide proper names
-
-```
- wrap
- wrap:mvn:foo.bar/baz/1.0.0$Bundle-Name=Foobar%20Baz%20Library&Bundle-SymbolicName=foo.bar.baz&Bundle-Version=1.0.0
-```
-
-** Internal dependency **
-
-In two cases libraries can be added to the `/lib` directory:
-1. The bundle is not available for download
-2. The bundle is not an OSGi bundle but needs to be used for integration tests.
-Unlike Karaf, BND is not able to wrap bundles on its own.
-In this case the binding works as wrapper.
-You need add the library and export all needed packages manually.
-
-The build system automatically picks up all JAR files in `/lib` and embeds them in the new bundle.
-In this case they must not be added to the feature.
-
-If the bundles manifest is not properly exporting all needed packages, you can import them manually by adding
+Bundles that are used in more than one binding should use the same version that is already present.
+You need to exclude those bundles from embedding by adding an exclusion to the `pom.xml`:
```
- foo.bar.*,foo.baz.*
+ netty-common
```
-to the POM.
+It is also necessary to add them to the `feature.xml`(see above).
+If the version that is used in other openHAB bundles is incompatible with your library, check if you can use a different version of your library.
+In case this is not possible, please ask if an exception can be made and a different version can be bundled within your binding.
+Technically you just need to omit the exclusion-statement above.
+If you only depend on shared bundles you can also omit the exclusion statement and add a `noEmbedDependencies.profile` file in the root directory of your binding.
If the imported packages need to be exposed to other bundles (e.g. case 2 above), this has to be done manually by adding
@@ -81,4 +73,40 @@ If the imported packages need to be exposed to other bundles (e.g. case 2 above)
to the POM.
If `version="1.0.0"` is not set, the packages are exported with the same version as the main bundle.
Optional parameters available for importing/exporting packages (e.g. `foo.bar.*;resolution:="optional"`) are available, too.
-Packages can be excluded from import/export by prepending `!` in front of the name (e.g. `!foo.bar.*' would prevent all packages starting with foo.bar from being imported).
+Packages can be excluded from import/export by prepending `!` in front of the name (e.g. `!foo.bar.*` would prevent all packages starting with foo.bar from being imported).
+
+## Karaf Feature
+
+Each bundle needs a `feature.xml` which is used for the bundle-installation in openHAB.
+A "fits-most-cases" `feature.xml` is automatically generated.
+
+In some cases additional entries need to be added.
+
+### Shared Dependencies (JNA, Netty, etc.)
+
+Bundles that are shared by different openHAB bundles are excluded from embedding.
+The need to be added to the feature to make them available at runtime.
+Two cases need to be treated differently:
+
+1. Bundles that have a core feature are referenced by the feature (e.g. `openhab-runtime-jna` or `openhab-transport-upnp`).
+2. Bundles that do not have a core feature are added directly (e.g. `mvn:commons-codec/commons-codec/1.10`).
+
+### Multi-Bundle Features / Sub-Bundles
+
+In some cases a binding consists of several bundles (e.g. `mqtt`).
+The `feature.xml` of the sub-bundle (e.g. `mqtt.homie`) needs to add all bundles from the parent-bundle to make sure that the feature verification suceeds:
+
+```
+openhab-transport-mqtt
+mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt/${project.version}
+```
+
+To make sure that all sub-bundles are installed together with the main-bundle, the `feature.xml` of the bundles needs to be excluded from the aggregation.
+Therefore an exclusion needs to be added to `features/openhab-addons/pom.xml` (starting from l. 47):
+
+```
+
+```
+
+An "aggregated" feature then needs to be created in `features/openhab-addons/src/main/resources/footer.xml`.
+The feature is named like the base-bundle and lists all sub-bundles.