diff --git a/_book/800-known-issues.md b/_book/800-known-issues.md
deleted file mode 100644
index 9038352..0000000
--- a/_book/800-known-issues.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: Known Issues
-layout: default
----
-
-* Dropping on the `Build Path` list from JPM does not work, nothing is shown. Workaround: Drop on the `Central` repository in the Repositories view (left bottom in the Bndtools Perspective). We're working on fixing this.
-
-
diff --git a/_book/900-faq.md b/_book/900-faq.md
index 5dc2ee7..a8871b2 100644
--- a/_book/900-faq.md
+++ b/_book/900-faq.md
@@ -1,6 +1,6 @@
---
title: Frequently Asked Questions
-layout: default
+layout: prev-next-collection
---
diff --git a/_config.yml b/_config.yml
index 775c796..85c8258 100644
--- a/_config.yml
+++ b/_config.yml
@@ -28,6 +28,8 @@ collections:
output: true
doc:
output: true
+ faq:
+ output: true
tutorial_base:
output: true
tutorial_rsa:
@@ -38,6 +40,10 @@ collections:
output: true
tutorial_maven:
output: true
+ tutorial_wrap:
+ output: true
+ videos:
+ output: true
defaults:
-
diff --git a/_data/sidebar.yml b/_data/sidebar.yml
index 569b53c..8c6eda7 100644
--- a/_data/sidebar.yml
+++ b/_data/sidebar.yml
@@ -43,6 +43,8 @@ nav:
external: true
- title: enRoute classic
links:
+ - name: Introduction
+ url: "/book/100-introduction.html"
- name: About OSGi
url: "/book/210-doc.html"
urlprefix: "/doc/"
diff --git a/_faq/class-not-found-exception.md b/_faq/class-not-found-exception.md
new file mode 100644
index 0000000..89a56ca
--- /dev/null
+++ b/_faq/class-not-found-exception.md
@@ -0,0 +1,65 @@
+---
+title: What is NoClassDefFoundError?
+summary: Explains the consequences of the class loading architecture
+---
+
+A very common question for new users of OSGi is as follows:
+
+> “My bundle throws a NoClassDefFoundError on 'org.example.FooBar' even
+> though FooBar is on the classpath. What's going on??”
+
+In OSGi, it doesn't even make sense to say that something is “on the
+classpath” because **there is no global classpath in OSGi**. Instead,
+each bundle has its own isolated class loader. The loader inside each
+bundle can *only* load classes that are either inside the bundle, or
+*explicitly imported* from another bundle.
+
+The preferred way to import from other bundles is to use
+`Import-Package`. You must import **every** package used by your bundle,
+with the exception of packages that are already part of your bundle and
+packages that begin with “java.” (for example `java.net`, `java.util`
+etc... these packages are treated specially by the JRE).
+
+If this sounds like a lot of work, don't worry! Many developers use
+[Bnd] to build their bundles, or a tool based on it such as [Bndtools]
+or [Maven Bundle Plugin]. All of these tools automatically generate the
+`Import-Package` header for your bundle, by inspecting all of the
+dependencies in your class files.
+
+Note that if your bundle imports a package, there must be another bundle
+installed in the OSGi Framework that exports the same package using the
+`Export-Package` header. At runtime the Framework matches each import
+with a corresponding export. If it can't find a matching export then
+your bundle will fail to resolve. This happens early in the lifecycle of
+a bundle, before any code is loaded, so as long as your imports are
+correct then you should never see errors like ClassNotFoundException or
+NoClassDefFoundError.
+
+### Differences between ClassNotFoundException and NoClassDefFoundError
+
+Both the `ClassNotFoundException` and `NoClassDefFoundError` may be seen
+when using Java libraries that try and load classes reflectively. This
+typically involves a Java library using `Class.forName` to load a class.
+
+#### ClassNotFoundException
+
+A `ClassNotFoundException` is generated by a call to `Class.forName()`
+with a `String` that contains a class not available on the bundle's
+class path. Unless the bundle has a
+[Import-Package](Import-Package "wikilink") or
+[Require-Bundle](Require-Bundle "wikilink") for the package in question
+(or a [DynamicImport-Package](DynamicImport-Package "wikilink")), the
+runtime will not be able to find the appropriate `.class`.
+
+#### NoClassDefFoundError
+
+A `NoClassDefFoundError` is generated when a class has been found, but
+one of its dependencies (typically, that involved in a static
+initialiser block) cannot be. For example, if class `A` refers to `B`,
+and `B` refers to `C`, then a client looking up A may work, but B (or C)
+could be missing. This would generate the error message
+`NoClassDefFoundError: A`.
+
+[Bndtools]: http://bndtools.org
+[Maven Bundle Plugin]: http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
+[Bnd]: http://bnd.bndtools.org
\ No newline at end of file
diff --git a/_faq/ds-inheritance.md b/_faq/ds-inheritance.md
new file mode 100644
index 0000000..ff97423
--- /dev/null
+++ b/_faq/ds-inheritance.md
@@ -0,0 +1,21 @@
+---
+title: Why does DS Annotations not support inheritance?
+summary: It seems logical to inherit the annotations for the bind methods and activate from a super class. This FAQ explains why it is not officially supported so far.
+---
+
+Felix Meschberger answered this question very eloquently on a question on the Bndtools list:
+
+> You might be pleased to hear that at the Apache Felix project we once had this feature in our annotations. From that we tried to standardize it actually.
+>
+> The problem, though, is that we get a nasty coupling issue here between two implementation classes across bundle boundaries and we cannot express this dependency properly using Import-Package or Require-Capability headers.
+>
+> Some problems springing to mind:
+>
+> Generally you want to make bind/unbind methods private. Would it be ok for SCR to call the private bind method on the base class ?(It can technically be done, but would it be ok).
+> What if we have private methods but the implementor decides to change the name of the private methods — after all they are private and not part of the API surface. The consumer will fail as the bind/unbind methods are listed in the descriptors provided by/for the extension class and they still name the old method names.
+> If we don’t support private method names for that we would require these bind/unbind methods to be protected or public. And thus we force implementation-detail methods to become part of the API. Not very nice IMHO.
+Note: package private methods don’t work as two different bundles should not share the same package with different contents.
+>
+> We argued back then that it would be ok-ish to have such inheritance within a single bundle but came to the conclusion that this limitation, the explanations around it, etc. would not be worth the effort. So we dropped the feature again from the roadmap.
+
+This all said, if you still want to try to shoot yourself in the foot: Bnd already supports this with -dsannotations-options: inherit.
diff --git a/_faq/unable-to-resolve-missing-false.md b/_faq/unable-to-resolve-missing-false.md
new file mode 100644
index 0000000..0bbd39d
--- /dev/null
+++ b/_faq/unable-to-resolve-missing-false.md
@@ -0,0 +1,21 @@
+---
+title: Unable to resolve org.example.foo.api version=1.0.0.201603042130 missing requirement false
+summary: When the resolver fails to resolve and says the missing requirement is false.
+---
+
+The resolve error indicates that the only exporter is the API project but that this project says it should not resolve because in enRoute we highly recommend to include the API package in the provider so a resolution does not just consist of APIs without implementations. If you look in your bnd.bnd file in the org.example.foo.api project then you'll see the following lines:
+
+Require-Capability: \
+compile-only
+
+This is a requirement that cannot be resolved. Adding the package to the provider will then make the provider the preferred exporter.
+
+This model (exporting the API from the provider) is explained extensively in the [Base Tutorial][1]. For a more information you can also look in the [bnd manual about versioning][2].
+
+You should there have some org.example.foo.provider bundle that provides the implementation and this should export the API. Exporting it is simple, just drag the package and drop it on the Contents Export list of the provider's `bnd.bnd` file. See the Base tutorial for details.
+
+That said, in the OSGi we now have implementation capabilities and the next OSGi enRoute setup will use those. It is slightly cleaner but also a bit less practical. For now, just export the API from the provider it is the last amount of trouble.
+
+
+[1]: /tutorial_base/300-api.html
+[2]: http://bnd.bndtools.org/chapters/170-versioning.html
diff --git a/_faq/unable-to-resolve.md b/_faq/unable-to-resolve.md
new file mode 100644
index 0000000..f6a6b31
--- /dev/null
+++ b/_faq/unable-to-resolve.md
@@ -0,0 +1,15 @@
+---
+title: Can't Resolve!
+summary: What to do when you cannot resolve a bndrun file
+---
+
+If you run in the problem that you can't resolve and have a problem understanding, here are some tips.
+
+First, try to resolve ONLY the provider (i.e. is the only requirement in the bndrun file) and see what it says. Likely the provider has a problem. You could also add the bundle that is reported as the last item in the diagnostic information from the resolver in the blacklist in your bndrun file. For example:
+
+ -runblacklist.eval: \
+ osgi.identity;filter:=‘(osgi.identity=com.example.foo.provider)
+
+The resolver will then probably provide the next thing it cannot resolve. Which unfortunately is often quite logical and simple :-(
+
+The resolver is pretty bad in telling what the culprit is. The reason is that it uses back-tracking. So the diagnostics are basically the last thing that was tried.
\ No newline at end of file
diff --git a/_faq/what-does-osgi-stand-for.md b/_faq/what-does-osgi-stand-for.md
new file mode 100644
index 0000000..b4a541e
--- /dev/null
+++ b/_faq/what-does-osgi-stand-for.md
@@ -0,0 +1,9 @@
+---
+title: What does OSGi stand for?
+summary: Is it an acronym or a name?
+---
+
+It doesn't stand for anything any more, it's just OSGi. Note the
+lower-case i when writing the name.
+
+
diff --git a/_tutorial_wrap/050-start.md b/_tutorial_wrap/050-start.md
new file mode 100644
index 0000000..2864536
--- /dev/null
+++ b/_tutorial_wrap/050-start.md
@@ -0,0 +1,64 @@
+---
+title: JAR Wrapping Tutorial
+layout: prev-next-collection
+noindex: true
+---
+
+This tutorial is under review. Feedback appreciated (PRs on [Github](https://github.com/bndtools/bndtools.github.io/tree/master/_tutorial_wrap))
+{: .note }
+
+## Why to wrap JAR files?
+
+OSGi developers face a challenge when using third-party libraries that are not supplied as OSGi bundles. Though an increasing number of libraries are available from their original sources as OSGi bundles, and a large number are available as wrapped OSGi bundles from external repositories, it is still sometimes necessary to build such a wrapper ourselves. This tutorial details an approach to OSGi bundle production using bnd/bndtools/gradle.
+
+## What you learn in this tutorial.
+
+In this quick start we learn how to _wrap_ a JAR to become a Bundle. Wrapping a JAR means that we need add the required OSGi manifest headers but also _design_ the contents of the bundle. Modularity is not about fences, modularity is about what you put inside those fences and what passages you allow. The bnd tool provides an overwhelming amount of instructions and features to create the Bundle you want; this tutorial tries to shine light on what forces are in play and what tools are available.
+
+This tutorial teaches the wrapping from the perspective of a Bndtools user. For any command line zealots this should not be too hard to map to `vi` since all we do is write a `bnd.bnd` file in Bndtools, which is also usable in for example Maven. The key advantage of Bndtools is that it shows you the missing packages interactively. If you want to stay on the command line, then you could take a look at [bnd Wrapping](https://bnd.bndtools.org/chapters/390-wrapping.html).
+
+In the coming chapters it is assumed you have a workspace ready. If you've no clue what we're talking about suggest you follow the [Quick Start] tutorial first.
+
+**A disclaimer.** This wrapping tutorial is about learning to use wrapping bundles inside the OSGi enRoute tool chain, it is not about learning Java, Git, nor Eclipse. It is assumed that you have basic experience with these tools and that you have at least followed the [Quick Start] tutorial.
+
+If you're just interested in the end result, you can look at the (archived) [osgi.enroute.examples.wrapping.dom4j.adapter] project.
+
+If you have any questions about this wrapping tutorial, please discuss them in the [Forum].
+
+## Sections
+
+
+
+
+
+
+
+
+{% for qs in site.tutorial_wrap %}{%unless qs.noindex%}| {{qs.title}} | {{qs.summary}} |
+{%endunless%}{% endfor %}
+
+
+
+
+
+## End
+
+So, you've finished this wrapping tutorial! What's next?
+
+Well, first, since we're still in beta, we'd love feedback. Our most favorite feedback is a pull request on the documentation. We, and others like you, highly appreciate these kind of contributions.
+
+If you've become interested in what bnd can do for you, then you could look at the [wrapping with bnd] chapter in the bnd manual.
+
+However, running into real problems is the best way to learn a technology. If you run into problems, use the [Forum] to ask questions and get answers.
+
+[forum]: https://bnd.discourse.group/
+[Quick Start]: /qs/050-start
+[wrapping with bnd]: https://bnd.bndtools.org/chapters/390-wrapping.html
+[-conditionalpackage]: https://bnd.bndtools.org/instructions/conditionalpackage.html
+[133 Service Loader Mediator Specification]: https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: https://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: https://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: https://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/100-shouldyou.md b/_tutorial_wrap/100-shouldyou.md
new file mode 100644
index 0000000..26b05a2
--- /dev/null
+++ b/_tutorial_wrap/100-shouldyou.md
@@ -0,0 +1,40 @@
+---
+title: Should You?
+summary: Consider alternatives to wrapping a bundle yourself, realize you do incur a long term technical debt.
+layout: prev-next-collection
+---
+
+Before we continue we must raise the question: "Do you really need that dependency?" In the software world we have an abundance of open source projects that provide us with almost any desired functionality today. The fact that a JAR is not _OSGified_ is actually a warning sign because adding the minimal OSGi headers requires very little work. Almost all successful open source libraries nowadays include OSGi support out of the box.
+
+The second warning sign you should be aware off is the sheer number of dependencies. If your target JAR has > ±10 external dependencies then you should seriously consider skipping it if it is anyway possible. Though it is okay for applications to have this many dependencies, it is _extremely_ painful to have a component with such a large fan out. Not only are such dependencies tedious, over time they tend to become an unsolvable problem because the dependencies of this component start to constraint your own dependencies.
+
+A good component is highly _cohesive_ and has minimal (preferably API based) dependencies.
+
+The third thing to consider is that OSGi is not about class loading; it is about _services_. The highest value in OSGi lies in its service model. With the service model it is possible to keep virtually all implementation details hidden inside the bundle. Unfortunately, writing service oriented bundles is an architectural aspect; it is hard to add this in general to a JAR that is written to reside on the class path and thrive on class loader hacks.
+
+## Which bundle has the package?
+
+And we hardly dare to raise the issue, did someone already provide the wrapped bundle for you?
+
+This is still difficult. Your best chances are:
+
+- Search for the package in a Search engine like Google
+- or ask one of the AI Tools like ChatGPT, Perplexity, Deepseek etc.
+
+The find the dependeny on Maven Central, copy the GAV coordinates and add them to your repository in bnd / bndtools.
+
+There are also some resources on the net that provide wrapped bundles:
+
+* [Eclipse Orbit](http://www.eclipse.org/orbit) – An Eclipse repository with OSGi bundles derived from open source projects.
+* Legacy: [Amdatu](https://repository.amdatu.org/) – Amdatu maintains a set of dependencies that are bundles
+
+Ok, you're still here ... So I guess the need is dire. Let's see how we can wrap an existing bundle.
+
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/150-strategy.md b/_tutorial_wrap/150-strategy.md
new file mode 100644
index 0000000..a20ce8b
--- /dev/null
+++ b/_tutorial_wrap/150-strategy.md
@@ -0,0 +1,43 @@
+---
+title: Strategy
+summary: How do we go about wrapping a bundle? What are the forces?
+layout: prev-next-collection
+---
+
+Though you can simply add the manifest headers to a JAR and make it an official bundle it is recommended to take a look at its dependencies. Good bundles are _cohesive_. That is, they perform one well defined function and make that available through a minimal API.
+
+Their dependencies are minimal and are of the _abstraction_ type. That is, a good bundle should not depend on a library like Guava because it was convenient to use a very small set of types from this huge library. A dependency should be a point where the outer application can provide a specific implementation that fits its requirements. Due to the abstraction points, a bundle can then live in many different contexts.
+
+The strategy for good bundles is therefore to hide any implementation dependencies and only import and export API packages. Obviously, this is the goal and not always achievable. It is especially hard for JARs that are not modular, the majority.
+
+A simple strategy would be to export all packages (`Export-Package: *`) and let *bnd* do the work.
+
+Unfortunately when wrapping third-party libraries it sometimes is not sufficient to simply accept the generated `Import-Package` statement: the result may need to be fine-tuned. This is because many third-party libraries contain dependencies that are out of place, often due to errors resulting from a lack of good modular practices.
+
+**For example:**
+
+- Classes that implement *optional* features are sometimes placed into a
+ library’s "core" JAR. For example the Log4J library includes
+ optional "appenders" for writing log messages to emails, JMS queues
+ and JMX/JDMK. As a result it depends on inter alia the javax.jms
+ package, and we have to include the JMS API bundle in order for
+ logging to work at all!
+- In other cases a library may contain "dead code" — i.e. code that is
+ not reachable from the public API — and that code may have external
+ dependencies.
+
+Bnd detects dependencies statically by inspecting all code in the library; it cannot determine which parts of the library are reachable. For example a common error is to include JUnit test cases in a library JAR, resulting in dependencies on JUnit. Unless fixed, the bundle will only be usable in a runtime environment where JUnit is also present, i.e., we will have to ship a copy of JUnit to our end users.
+
+In this tutorial we will follow the strategy of exporting all the packages but then carefully craft the resulting bundle based on the different problems one typically encounters wrapping bundles.
+
+That said, the actual wrapping is contrived, it is not an actual industrial ready wrapping.
+
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/200-project.md b/_tutorial_wrap/200-project.md
new file mode 100644
index 0000000..e8be0aa
--- /dev/null
+++ b/_tutorial_wrap/200-project.md
@@ -0,0 +1,129 @@
+---
+title: Creating the Initial Project
+summary: Setup the project with DOM4J and make an initial cut
+layout: prev-next-collection
+---
+
+In this tutorial we will wrap [DOM4J]. This JAR is available on Maven Central. The latest versions are actually OSGi enabled but there are variations around without manifest headers. It is chose because its dependencies are not too awful. It also depends on a number of external libraries that each also have dependencies, ad nauseum.
+
+> ##### WARNING
+>
+> The work we do in this tutorial **is not for use in a real bundle**. The resulting bundle is not tested an might not work. The only goal is to show the forces at play when you wrap a bundle.
+{: .block-warning }
+
+## Dependencies of DOM4J
+
+Below you see the dependency graph of revision 1.6.1. For an average Maven project this actually looks quite good. (The graph shows all Maven dependencies, this is in general a bit too wide since test and compile dependencies are not transitive.) However, if a project does not stop at the maximum number of shown dependencies (>1000) then it is generally a 'good' sign.
+
+{: width="70%" }
+
+On Maven Central you can see this in the [Dependencies tab](https://central.sonatype.com/artifact/dom4j/dom4j/1.6.1/dependencies).
+
+After we created the project, we'll drag the top version vignette on the `bnd.bnd` build tab to add it as a dependency.
+
+## Creating Project
+
+In Bndtools create a project `osgi.enroute.examples.wrapping.dom4j.adapter`. It is of course fine to call it differently but make sure you call make the extension `adapter` or `provider`. This extension triggers the correct template with the OSGi enRoute templates, which you should obviously use.
+
+After the creation, you can delete the source code in the `src` and `test` source folders; we won't use it. (Add a `.gitignore` file in the `src` folder so that it is not ignored as an empty directory by Git.)
+
+## Adding DOM4J
+
+First, add the Maven GAV coordinates, i.e. `dom4j:dom4j:1.6.1` to your repository in bndtools (e.g. [MavenBndRepository](https://bnd.bndtools.org/plugins/maven.html))
+
+Then double click on the `bnd.bnd` file in your project and select the `Build` tab. Now drag the domj bundle from the Repository Browserto the `Build` tab's `Build Path` list and drop it. Alternatively you can achieve the same by using the `+` Button of the `Build Path` list.
+
+Then, click on the `Source` tab. The `-buildpath` looks then like:
+
+ -buildpath: \
+ dom4j:dom4j;version='1.6'
+
+## Version & Description
+
+In general you use the version of the JAR you're wrapping. Since we're wrapping 1.6.1 we make that our own version. It is also a good idea to add a small description of what you are doing. So you should replace the Bundle-Version and Bundle-Description headers. Adding a Bundle-Copyright and Bundle-Vendor cannot harm:
+
+ Bundle-Version: 1.6.1.${tstamp}
+ Bundle-Description: Wraps DOM4J for OSGi, including the primary dependencies
+ Bundle-Copyright: OSGi enRoute
+ Bundle-Vendor: OSGi Alliance
+
+## Build Path
+
+If you save the `bnd.bnd` file then the DOM4J JAR is added to your _build path_. We can inspect the contents by
+looking in the Eclipse Class Path container. This is the little bookshelf with the title: `Bnd Bundle Path`. The little arrow on the left allows you to open the container to see the contents. Also open the `dom4j-1.6.1` member of this container.
+
+{: width="70%" }
+
+## Exporting
+
+Inspecting the list of packages inside the `dom4j-1.6.1` JAR shows that all package names start with `org.dom4j`. We therefore start by exporting these packages. The easiest way to do this to stay in the `Source` tab and add the text:
+
+ Export-Package: org.dom4j.*
+
+This will export all packages on the `-buildpath` that start with `org.dom4j`!
+
+## The Bundle
+
+We've actually generated the bundle now. If you look in the folder `generated` then you'll find the JAR . Opening this JAR in the JAR Editor that is included with Bndtools will show you the manifest. (The `Print` tab is a little more readable.) This manifest looks (slightly reformatted) like:
+
+ [MANIFEST osgi.enroute.examples.wrapping.dom4j.adapter.jar]
+ Bnd-LastModified 1458829936934
+ Bundle-Copyright OSGi enRoute
+ Bundle-Description Wraps DOM4J for OSGi, including
+ the primary dependencies
+ Bundle-ManifestVersion 2
+ Bundle-Name osgi.enroute.examples.wrapping.dom4j.adapter
+ Bundle-SymbolicName osgi.enroute.examples.wrapping.dom4j.adapter
+ Bundle-Vendor OSGi Alliance
+ Bundle-Version 1.6.1.201603241432
+ Created-By 1.8.0_25 (Oracle Corporation)
+ Import-Package com.sun.msv.datatype,
+ com.sun.msv.datatype.xsd,
+ javax.swing.table,
+ javax.swing.tree,
+ javax.xml.namespace,
+ javax.xml.parsers,
+ javax.xml.stream,
+ javax.xml.stream.events,
+ javax.xml.stream.util,
+ javax.xml.transform.sax,
+ org.gjt.xpp,
+ org.jaxen,org.jaxen.dom4j,
+ org.jaxen.pattern,
+ org.jaxen.saxpath,
+ org.relaxng.datatype,
+ org.w3c.dom,
+ org.xml.sax,
+ org.xml.sax.ext,
+ org.xml.sax.helpers,
+ org.xmlpull.v1
+ Manifest-Version 1.0
+ Private-Package org.dom4j.rule.pattern,
+ org.dom4j.swing,
+ org.dom4j.tree,
+ org.dom4j.dtd,
+ org.dom4j.util,
+ org.dom4j.xpp,
+ org.dom4j,
+ org.dom4j.bean,
+ org.dom4j.datatype,
+ org.dom4j.rule,
+ org.dom4j.io,
+ org.dom4j.xpath
+ Require-Capability osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.3))"
+ Tool Bnd-3.2.0.201603172351-SNAPSHOT
+
+Obviously we succeeded in including the `org.dom4j` packages but we got a few imports that are not in the JVM like `org.jaxen`, `org.gjt.xpp`, and `org.relaxng`.
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/210-dependencies.md b/_tutorial_wrap/210-dependencies.md
new file mode 100644
index 0000000..9b4a545
--- /dev/null
+++ b/_tutorial_wrap/210-dependencies.md
@@ -0,0 +1,51 @@
+---
+title: Adding Missing Dependencies
+summary: To ensure proper versioning we need to add the dependencies on the -buildpath
+layout: prev-next-collection
+---
+
+Click on the `bnd.bnd` file and select the `Contents` tab. You will see the exports listed in the `Export Packages` list and the `Calculated Imports` the list of actual imports. Clearly we're missing a few files on the `-buildpath`.
+
+{: width="70%" }
+
+Let's start with the first non-JVM dependency: `com.sun.msv.datatype`.
+
+We can search this on Google and you may end up [here](https://mvnrepository.com/artifact/net.java.dev.msv), where you see a couple of results:
+
+Obviously we have a choice here ... You will have to use external information, common sense, and some luck to get the right one. Unfortunately the rest of the world does not organize packages very well. This uncertainty is one of the main reasons why this process is so tedious.
+
+Let's pick the [ net.java.dev.msv : xsdlib @ 2013.6.1](https://mvnrepository.com/artifact/net.java.dev.msv/xsdlib/2013.6.1) and add it to our build path.
+
+For the `bnd.bnd` file select the `Build` tab and then drop the version vignette on the `Build Path` list. (Remember the bug, might cause it to take a bit, working on it.) If you save the `bnd.bnd` file and look at the `Source` tab then you should have the following `-buildpath`:
+
+ -buildpath: \
+ dom4j:dom4j;version='1.6',\
+ net.java.dev.msv.xsdlib;version='2013.6'
+
+
+And if you go to the `Content` tab you will see that the `com.sun.msv.datatype` and `com.sun.msv.datatype.xsd` now have an import version range applied to it `\[2013.6.1,2014)`. This version range is calculated by bnd from the exported version of that package by the `net.java.dev.msv.xsdlib;version=2013.6.1` bundle. (It is actually a bundle!)
+
+{: width="70%" }
+
+However, it is still a dependency. This raises the choice of _dependending_ on that dependency or including it? We will handle all cases, but first lets include ALL our dependencies.
+
+
+
+We did!
+
+
+
+
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/212-conditional-package.md b/_tutorial_wrap/212-conditional-package.md
new file mode 100644
index 0000000..516ca2c
--- /dev/null
+++ b/_tutorial_wrap/212-conditional-package.md
@@ -0,0 +1,68 @@
+---
+title: Static linking our Dependencies (Conditional Package)
+summary: In our first attempt we statically link the imported packages recursively
+layout: prev-next-collection
+---
+
+The bnd tool contains a nifty feature that it inherited from old school C. In those days, the link phase searched for missing symbols in libraries and automatically included those functions from the library in your code. This was called [static linking](https://kb.iu.edu/d/akqn). Neil Bartlett wrote a [blog] about the subject.
+
+The [-conditionalpackage] instruction performs a similar function for packages. It analyzes the bundle and it will then look on the `-buildpath` for the missing packages. It then adds those packages and analyzes again recursively. There is a caveat that sometimes packages are not sufficient, sometimes there are resources that must be included as well. We'll discuss those issues later.
+
+This is of course very useful, in our wrapper bundle we only want to import from the JVM. All other dependencies should be included. Since we can ignore java.\* packages (they are **always** coming from the JVM), we need to filter out any packages that might come from the VM. All other packages can be copied from the `-buildpath`. We can exclude packages with the `!` operator. So we first exclude the packages from the JVM and then we use the wildcard ('*') to include the remaining packages from the `-buildpath`. This looks as follows.
+
+ -conditionalpackage: \
+ !javax.*, \
+ !org.xml.*, \
+ !org.w3c.*, \
+ !org.ietf.jgss, \
+ !org.omg.*, \
+ *
+
+Since our `-buildpath` looked like:
+
+ -buildpath: \
+ dom4j:dom4j;version='1.6',\
+ net.java.dev.msv.xsdlib;version='2013.6'
+
+We should now have included the `com.sun` packages. We can verify this by by opening the `osgi.enroute.examples.wrapping.dom4j.adapter.jar` file from the `generated` directory in the JAR Editor. At the end of the `Print` tab there is a list of contents and this now contains the `com.sun` packages.
+
+ ...
+ com
+ com/sun
+ com/sun/msv
+ com/sun/msv/datatype
+ DatabindableDatatype.class
+ ErrorDatatypeLibrary.class
+ SerializationContext.class
+ com/sun/msv/datatype/xsd
+ AnyURIType.class
+ ...
+
+
+We will have to repeat this process for each package that is not included in the the JVM. For Java 1.8, the following `-buildpath` had no more extraneous imports:
+
+ -buildpath: \
+ dom4j:dom4j;version='1.6',\
+ net.java.dev.msv.xsdlib;version='2013.6',\
+ xmlpull__xmlpull;version=1.1.3.4d_b4_min,\
+ pull-parser__pull-parser;version=2.1.10,\
+ jaxen;version=1.1.6,\
+ relaxngDatatype__relaxngDatatype;version=20020414.0
+
+We can look at the `Contents` tab of the `bnd.bnd` file to see if we covered all our inputs that do not originate from the JVM.
+
+{: width="50%" }
+
+Looks good but are we ready now? Hmm. We have not looked at all what the consequences are of including the packages. In the next section we go through the potential options and hazards.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/215-bundle-dependencies.md b/_tutorial_wrap/215-bundle-dependencies.md
new file mode 100644
index 0000000..3401ab6
--- /dev/null
+++ b/_tutorial_wrap/215-bundle-dependencies.md
@@ -0,0 +1,43 @@
+---
+title: Handling Dependencies on OSGi Bundles
+summary: When a dependency is already provided as a proper bundle we should probably not include it.
+layout: prev-next-collection
+---
+
+
+When we look in the `Bnd Bundle Path`, in the repository we can see that `org.jaxen` is an OSGi bundle. So in that case we could allow the import of its packages instead of wrapping it inside our bundle.
+
+When to refer and when to include. In general, dependencies are evil. Adding a dependency to save a few bytes is [usually not worth it](http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/). When systems become complex it quickly becomes really problematic to ensure that no two dependencies conflict on their versions. Though OSGi can handle multiple versions in a JVM, the consequences are still not anything to be desired for a reliable application.
+
+In a perfect world the only dependencies are therefore APIs to an _abstraction_ of a shared functionality. For example, you cannot include an Event Admin implementation because the whole purpose of that service is that it is shared between all bundles. However, you can include an ASM bytecode manipulation library since it is perfectly okay that different bundles use different versions of this library as long as they do not interchange types of it.
+
+Anyway. To make `jaxen` bundle an external dependency we need to add the `org.jaxen` packages to the `-conditionalpackage` instruction with a '!' so they will not be included in our bundle.
+
+ -conditionalpackage: \
+ !javax.*, \
+ !org.xml.*, \
+ !org.w3c.*, \
+ !org.ietf.jgss, \
+ !org.omg.*, \
+ !org.jaxen.*, \
+ *
+
+We could of course remove it from our `-buildpath` so bnd could not find it. That is, however, a bad idea. By leaving it on the `-buildpath` we allow bnd to _learn_ the versions of the packages so it can properly version the packages in our target bundle. If we look at our imports now in the `Contents` tab:
+
+{: width="50%"}
+
+We can see that the org.jaxen package is now imported with a real version range.
+
+One down, some more to go. What if we want to _optionally_ depend on something? Stay tuned.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/220-optional-dependencies.md b/_tutorial_wrap/220-optional-dependencies.md
new file mode 100644
index 0000000..481310a
--- /dev/null
+++ b/_tutorial_wrap/220-optional-dependencies.md
@@ -0,0 +1,58 @@
+---
+title: Handling Optional Dependencies
+summary: Sometimes dependencies are optional because they are only used when the optional dependency is present.
+layout: prev-next-collection
+---
+
+If we inspect list of included packages we find that `com.sun.msv.datatype` and `com.sun.msv.datatype.xsd` are included from `net.java.dev.msv.xsdlib`. They drag in quite a few classes so we would like to reference these as imports as well. (They are proper bundles.) However, we suspect that most of DOM4J would work without these dependencies. (Okay, strike that, we just make the unverified assumption.)
+
+You will often find the same structure in JARs. There is a core of highly interconnected packages and then there are a number of _satellite packages_ that import the core and some external dependency. In vein with the [supernodes of small worlds], these are the super packages. These packages _bridge_ the internal core with other, often large subsystems. It always is worth to pay attention to these _superpackages_ because they are often:
+
+* Not required by the core
+* Only needed when they are included in an application that already contains the bridged subsystem
+
+So these are typical _optional_ dependencies. We can leverage it when it is there, but we don't need it and we don't want to force our users to include it. For example, if a bytecode manipulation library includes a Maven plugin then it will have a dependency on the whole of Maven because it uses its API. Obviously, this will make the library not popular in Gradle or in a non-build tool environment.
+
+In OSGi, we can mark imported packages as optional by adding the directive `resolution:=optional` to the import package clause.
+
+So let us do an experiment. Lets add the package prefix `com.sun.*` to our `-conditionalpackage` instruction. This will then make us import the dependency. In the `Contents` tab we can then look which class is actually referring to those packages.
+
+ -conditionalpackage: \
+ !javax.*, \
+ !org.xml.*, \
+ !org.w3c.*, \
+ !org.ietf.jgss, \
+ !org.omg.*, \
+ !org.jaxen.*, \
+ !com.sun.*, \
+ *
+
+Save the file and open the `Contents` tab.
+
+{: width="50%" }
+
+As you can see in the previous picture, the classes that refer to the imported packages are now listed in the `Calculated Imports` list. From this we can take the decision if we make it an optional import because those classes. As stated before, lets assume these are bridge classes so the `com.sun.msv.datatype` and `com.sun.msv.datatype.xsd` are only needed in special occasions. (Again, we assume, we don't know for real.)
+
+We can augment the Import-Package header as follows:
+
+ Import-Package: \
+ com.sun.msv.datatype.*; resolution:=optional, \
+ *
+
+We can now look again at the `Contents` tab to see that the `com.sun.msv.datatype.*` packages are optionally imported. They have become gray and show `optional`:
+
+{: width="50%" }
+
+We've now made the `com.sun.msv` packages optional. However, in certain cases you just want to ignore the import because you have knowledge that the import can never be used. (Though the punishment for being wrong are hard to diagnose errors.)
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/225-ignoring-dependencies.md b/_tutorial_wrap/225-ignoring-dependencies.md
new file mode 100644
index 0000000..bea9796
--- /dev/null
+++ b/_tutorial_wrap/225-ignoring-dependencies.md
@@ -0,0 +1,52 @@
+---
+title: Ignoring Dependencies
+summary: In rare cases a dependency is never used and can then be ignored.
+layout: prev-next-collection
+---
+
+Further inspecting the list of included packages we see that we include two pull parsers:
+
+ xmlpull__xmlpull
+ pull-parser__pull-parser
+
+They both are quite old and (11 and 6 years) and not OSGi bundles. For the sake of this example, lets ignore the `xmlpull__xmlpull` dependency.
+
+ -conditionalpackage: \
+ !javax.*, \
+ !org.xml.*, \
+ !org.w3c.*, \
+ !org.ietf.jgss, \
+ !org.omg.*, \
+ !com.sun.*, \
+ !org.jaxen.*, \
+ !org.xmlpull.*, '\
+ *
+
+Inspecting the `Contents` tab, we can see that this imports `org.xmlpull.v1`. Since we do not want to create a dependency to a package that is not from a bundle, not even optional, we are going to ignore this import.
+
+In bnd, imports are controlled via the Import-Package header/instruction. By default, this header is `*`, the wildcard. This means that any import that is found by analyzing the bytecodes is added to the manifest. We can use this list to decorate the packages with attributes and directives. However, we can also use it to ignore certain packages. Ignoring is done in the same way as we do in the `-conditionalpackage` instruction, with the _bang_ (exclamation mark, '!'). Don't forget to end the instruction/header with the wildcard or you'll skip all imports.
+
+ Import-Package: \
+ com.sun.msv.datatype.*; resolution:=optional, \
+ !org.xmlpull.*, \
+ *
+
+If we now look at the imports in the generated directory then we see:
+
+
+
+{: width="50%"}
+
+No more XML Pull parsing! Caveat: If the pull parser is used internally then you're of course pickled. The effect will be a Class Not Found exception that any users will make them want to pull their hair out, or do that kind of activity to you. So don't do these tricks and publish the results until you really figured out that it cannot do any harm.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/230-extra-packages.md b/_tutorial_wrap/230-extra-packages.md
new file mode 100644
index 0000000..7a63be7
--- /dev/null
+++ b/_tutorial_wrap/230-extra-packages.md
@@ -0,0 +1,98 @@
+---
+title: Adding Extra Packages
+summary: Since the analysis is done by code not all packages that are required are found.
+layout: prev-next-collection
+---
+
+The `-conditionalpackage` instruction has given us a nice way to ensure that we've covered all package dependencies that _are discoverable by code inspection_. However, in certain cases there are resources that must be included. Unfortunately, bnd has no knowledge of those references. It is therefore necessary to copy those resources.
+
+For example, when we inspect the list of included packages (you can see them with the JAR Editor) we find that for the `pull-parser__pull-parser-2.1.10.jar` we only drag in one package `org.gjt.xpp`:
+
+ ...
+ org/dom4j/xpp
+ ProxyXmlStartTag.class
+ org/gjt
+ org/gjt/xpp
+ XmlEndTag.class
+ XmlFormatter.class
+ XmlNode.class
+ XmlPullNode.class
+ XmlPullParser.class
+ XmlPullParserBufferControl.class
+ XmlPullParserEventPosition.class
+ XmlPullParserException.class
+ XmlPullParserFactory.class
+ XmlRecorder.class
+ XmlStartTag.class
+ XmlTag.class
+ XmlWritable.class
+ org/relaxng
+ org/relaxng/datatype
+ ...
+
+This implies we do not carry the implementation, this is just the API. So we can add the implementation using the following instruction:
+
+ Private-Package: org.gjt.xpp.*
+
+If we now look in our bundle then we see:
+
+ ...
+ org/dom4j/xpp
+ ProxyXmlStartTag.class
+ org/gjt
+ org/gjt/xpp
+ XmlEndTag.class
+ XmlFormatter.class
+ XmlNode.class
+ XmlPullNode.class
+ XmlPullParser.class
+ XmlPullParserBufferControl.class
+ XmlPullParserEventPosition.class
+ XmlPullParserException.class
+ XmlPullParserFactory.class
+ XmlRecorder.class
+ XmlStartTag.class
+ XmlTag.class
+ XmlWritable.class
+ org/gjt/xpp/impl
+ PullParserFactoryFullImpl.class
+ org/gjt/xpp/impl/format
+ Formatter.class
+ Recorder.class
+ org/gjt/xpp/impl/node
+ EmptyEnumerator.class
+ Node.class
+ OneChildEnumerator.class
+ org/gjt/xpp/impl/pullnode
+ PullNode.class
+ PullNodeEnumerator.class
+ org/gjt/xpp/impl/pullparser
+ ElementContent.class
+ PullParser.class
+ org/gjt/xpp/impl/tag
+ Attribute.class
+ EndTag.class
+ PullParserRuntimeException.class
+ StartTag.class
+ Tag.class
+ org/gjt/xpp/impl/tokenizer
+ Tokenizer.class
+ TokenizerBufferOverflowException.class
+ TokenizerException.class
+ org/relaxng
+ org/relaxng/datatype
+ ...
+
+It should be clear that this could add additional imports so we should verify the `Contents` tab. Fortunately in this case we add a few additional packages form the external dependency `jaxen` bundle, no problem here.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/240-dynamic-references.md b/_tutorial_wrap/240-dynamic-references.md
new file mode 100644
index 0000000..959266b
--- /dev/null
+++ b/_tutorial_wrap/240-dynamic-references.md
@@ -0,0 +1,45 @@
+---
+title: Dynamic References
+summary: The code can depend on other code but this is not detected by the analysis
+layout: prev-next-collection
+---
+
+## Dynamic References
+
+Bnd discovers package dependencies in a bundle by scanning the bytecode
+of the compiled Java files. This process finds all of the static
+dependencies of the Java code, but it does not discover dynamic
+dependencies, for example those arising from the use of
+`Class.forName()`. There is no generic way for Bnd to calculate all
+dynamic dependencies. However there are certain well-known configuration
+formats that result in dynamic dependencies, and Bnd can analyse these
+formats through the use of plugins.
+
+For example, some bundles use the Spring Framework for dependency
+injection. Spring uses XML files that refer to fully qualified Java
+class names:
+
+
+
+
+Here the `org.example.beans` package is a dependency of the bundle that
+should be added to `Import-Package`. Bnd can discover this dependency by
+adding a Spring analyser plugin via a declaration in the descriptor
+file:
+
+ -plugin: aQute.lib.spring.SpringComponent
+
+Similar plugins exist for JPA and Hibernate, and custom plugins can be
+written to support other configuration formats or scripting languages.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/250-resources.md b/_tutorial_wrap/250-resources.md
new file mode 100644
index 0000000..5a67443
--- /dev/null
+++ b/_tutorial_wrap/250-resources.md
@@ -0,0 +1,34 @@
+---
+title: Resources
+summary: When the target bundle uses resources, like translations, these should also be copied with the -includeresource instruction.
+layout: prev-next-collection
+---
+
+JARs are extremely flexible, they can contain any type of resource. So far, we've only focused on packages. However, we can also copy resources from the JARs on our `-buildpath` (or file system) into our target JAR.
+
+The `pull-parser__pull-parser-2.1.10.jar` contains an (empty) file in the root of the JAR named `PullParser2.1.10_VERSION`. You can see that resource from the `Bnd Bundle Path` container. Maybe the parser assumes this resource in its root so we better make sure it is included. To include resources from the `-buildpath` or file system we use the `-includeresource` instruction.
+
+ -includeresource: \
+ @pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION
+
+The `-includeresource` instruction can take any resources from the file system but it has a nifty feature to also use resources from the `-buildpath`. If you prefix a resource with `@` then it will assume a JAR file. It will first look on the file system but if it is not there, it will look for that file name (not path) in the `-buildpath`. You could include the whole JAR but with the `!/` pattern you can single out a resource. (This is standard for JAR URLs.) The resource will then be copied to the same path in the target bundle.
+
+And as usual in bnd, you can use a wildcard character '*' to not hardcode the version number.
+
+You can verify that the resource made it in the JAR Editor.
+
+{: width="70%" }
+
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/260-source-code.md b/_tutorial_wrap/260-source-code.md
new file mode 100644
index 0000000..3cc1893
--- /dev/null
+++ b/_tutorial_wrap/260-source-code.md
@@ -0,0 +1,27 @@
+---
+title: Adding Source Code
+summary: OSGi Bundles can contain the source code in OSGI-OPT/src, this is recognized by IDEs during debugging
+layout: prev-next-collection
+---
+
+One of the nifty features of bundles is that they can carry their own sources. This feature is recognized by the better IDEs on the market. Having the source code in the IDE makes debugging a lot more friendly. However, in the Maven world (where most JPM4J dependencies come from) sources are in a separate JAR. We can ask JPM4J to create a combined JAR.
+
+If you go to the Bndtools Repository view and select the `dom4j:dom4j` entry for version is `1.6.1` then with *right-click* you can call up a menu on that entry. The menu contains an entry to `Add Sources` if the repository has source code for that artifact. This can take a few seconds because the sources must be downloaded.
+
+Once a bundle has source code, bnd will automatically also copy that source code when it copies a package. you can disable the source code with:
+
+ -sources: false
+
+This can be useful for proprietary code. Otherwise, always try to include the source code because it is a small overhead on disk and it is wonderful when you need it and it is already there.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/270-private-references.md b/_tutorial_wrap/270-private-references.md
new file mode 100644
index 0000000..6c62f39
--- /dev/null
+++ b/_tutorial_wrap/270-private-references.md
@@ -0,0 +1,39 @@
+---
+title: Warning, Private References
+summary: Private references are references from an exported package to a private packages. Since they can cause grief, they need to be cleaned up.
+layout: prev-next-collection
+---
+
+If you pay attention to warnings (and you should!) then you should have noticed that we're having a number of _private references_ warning. A private reference warning means that an exported package uses a type from a private package in its public API. The implication is that that API is not possible to use since the needed types are private.
+
+Unfortunately, many libraries are badly designed and the types referred are actually just part of a private API. It is one of the reasons why it is sometimes worth to not use external JARs.
+
+However, in this case we need to export more packages than `org.dom4j.*`. The warnings in the `Problems` view in Eclipse provide you with the following information:
+
+ Export org.dom4j.datatype, has 1, private references [org.relaxng.datatype]
+
+This means that the `org.dom4j.datatype` uses types from `org.relaxng.datatype` in its **public** API. We will therefore have to export `org.relaxng.datatype` as well. Looking at the warnings we have the following private references
+
+ org.relaxng.datatype
+ org.gjt.xpp
+
+You could investigate if they are really needed (they could be superpackages) for your purpose but let's add them to the exports.
+
+ Export-Package: \
+ org.dom4j.*, \
+ org.relaxng.datatype, \
+ org.gjt.xpp
+
+In this case we were lucky, adding them to the export list gets rid of the private reference warnings.
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
diff --git a/_tutorial_wrap/280-versioning.md b/_tutorial_wrap/280-versioning.md
new file mode 100644
index 0000000..4fb19a1
--- /dev/null
+++ b/_tutorial_wrap/280-versioning.md
@@ -0,0 +1,80 @@
+---
+title: Versioning the Packages
+summary: The hard part, what versions should the exported packages have?
+layout: prev-next-collection
+---
+
+So far we've ignored the nasty concept of _versions_. We were forced to export a lot of packages that are not [semanticaly versioned]. By default, bnd gives these packages the version of their bundle, which is an awful defaultbut we don't know any better. In our example, this looks like:
+
+ Export-Package
+ org.dom4j {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.bean {version=1.6.1}
+ org.dom4j.datatype {version=1.6.1}
+ org.dom4j.dtd {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.io {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.rule {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.rule.pattern {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.swing {version=1.6.1}
+ org.dom4j.tree {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.util {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.xpath {version=1.6.1, imported-as=\[1.6,2)}
+ org.dom4j.xpp {version=1.6.1, imported-as=\[1.6,2)}
+ org.gjt.xpp {version=2.1.10, imported-as=\[2.1,3)}
+ org.relaxng.datatype {version=1.0.0, imported-as=\[1.0,2)}
+
+
+Sadly, there is no good solution. It is one of those things where only the author can provide good semantic versions, anything someone else does will back fire one day. And this does makes sense because semantic versioning is basically a promise from the _author_ to signal the compatibility of future changes in the version number.
+
+Note that version ranges cannot be added for JRE packages, e.g.
+`javax.swing` or `org.xml.sax` because the Java specifications do not
+define the version of any of these packages, and therefore the OSGi
+framework exports them all as version 0.0.0. As an alternative, add a
+`Bundle-RequiredExecutionEnvironment` header to indicate the basic Java
+level required by the bundle:
+
+ Bundle-RequiredExecutionEnvironment: J2SE-1.8
+
+Other possible values include JavaSE-1.6, OSGi/Minimum-1.0, etc.
+
+If we wanted to control the versions in more detail we could decorate the Export-Package header. In general you then want to use macros to specify these versions so you won't have to repeat yourself.
+
+ version-dom4j = 1.6.1
+ version-relaxng = 1.0.0
+ version-gjt = 2.1.10
+ Export-Package: \
+ org.dom4j.*;version=${version-dom4j}, \
+ org.relaxng.datatype;version=${version-relaxng}, \
+ org.gjt.xpp;version=${version-gjt}
+
+This gives us an export list of:
+
+ Export-Package
+ org.dom4j {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.bean {version=1.6.1}
+ org.dom4j.datatype {version=1.6.1}
+ org.dom4j.dtd {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.io {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.rule {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.rule.pattern {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.swing {version=1.6.1}
+ org.dom4j.tree {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.util {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.xpath {version=1.6.1, imported-as=[1.6,2)}
+ org.dom4j.xpp {version=1.6.1, imported-as=[1.6,2)}
+ org.gjt.xpp {version=2.1.10, imported-as=[2.1,3)}
+ org.relaxng.datatype {version=1.0.0, imported-as=[1.0,2)}
+
+Whatever you do, the fact that the packages are not versioned by the author makes it a losing game. So this probably works when you use this bundle yourself but it is dangerous to publish it to the world or place it on maven central.
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/290-contracts.md b/_tutorial_wrap/290-contracts.md
new file mode 100644
index 0000000..a35db3b
--- /dev/null
+++ b/_tutorial_wrap/290-contracts.md
@@ -0,0 +1,47 @@
+---
+title: OSGi Contracts
+summary: ADVANCED. Sometimes OSGi Contracts can alleviate the versioning problem.
+layout: prev-next-collection
+---
+
+This is an advanced subject.
+{: .note }
+
+One possibility for the versioning problem in the previous section is to use _OSGi contracts_. An OSGi contract replaces the versions on the myriad packages with a single versioned name. This was concept was developed because the versions on servlet related packages was a disaster. This is outlined in [135.3 osgi.contract Namespace].
+
+Providing a contract is quite straightforward, you provide a capability that enumerates the packages that belong to the contract. The users of the bundle should then have a matching requireme capability. (bnd has support then to remove the versions from the package import, read [135.3 osgi.contract Namespace] for more information.)
+
+The capability that we provide for the contract must contain the list of packages in the `uses:` directive. Fortunately, the `${exports}` macro contains the list of all our exported packages in bnd. Saves us from maintaining this list by hand. So the capability would look like:
+
+ Provide-Capability: \
+ ... \
+ osgi.contract; \
+ osgi.contract=DOM4J; \
+ uses:="${exports}"; \
+ version:List
=1.0.0
+
+There is a bug in the OSGi specification, it lists `version=1.0.0` but it should be `version:List=1.0.0`.
+{:.bug}
+
+The bundles that use this DOM4J contract should now have a matching require capability like:
+
+ Require-Capability: \
+ ... \
+ osgi.contract; \
+ filter:="(&(osgi.contract=DOM4J)(version=1.0))"
+ -contract: DOM4J
+
+The `-contract` instruction tells bnd to remove the versions of all packages that are part of the contract.
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/300-serviceloader.md b/_tutorial_wrap/300-serviceloader.md
new file mode 100644
index 0000000..9e8ae0a
--- /dev/null
+++ b/_tutorial_wrap/300-serviceloader.md
@@ -0,0 +1,45 @@
+---
+title: Service Loader Services Integration
+summary: ADVANCED. The Java Service Loader uses a file in META-INF/services to load an implementation by its implemented interface. This requires some extra work in OSGi.
+layout: prev-next-collection
+---
+
+This is an advanced subject.
+{: .note }
+
+Several bundles support the Java VM's _Service Loader_ services. These services have a magic file in `META-INF/services` with the name of an interface. If the Service Loader wants to load a service for an interface it looks in the magic directory for files with the interface's name. It then reads the contents and loads the class with the name in that file. For example, `pull-parser__pull-parser-2.1.10.jar` contains the file `META-INF/services/org.gjt.xpp.XmlPullParserFactory`. The contents of this file is `org.gjt.xpp.impl.PullParserFactoryFullImpl`. Using the Service Loader to get a class that implements the `org.gjt.xpp.XmlPullParserFactory` interface will get you the `org.gjt.xpp.impl.PullParserFactoryFullImpl` class.
+
+So let's first add this Service Loader services file to the bundle:
+
+
+ -includeresource: \
+ @pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION, \
+ @pull-parser__pull-parser-2.1.10.jar!/META-INF/services/*
+
+In OSGi the Service Loader does not work because the class loader has no visibility inside your bundle. (That is the whole idea behind modularity!) However, in [133 Service Loader Mediator Specification] the OSGi specifies a service that can register these Service Loader services as ordinary OSGi services.
+
+There are different options, read the specification to see what you can do. According to the specification we must _advertise_ the Service Loader service and then require the `osgi.serviceloader.registrar` extender. Again, it is useful to read the [133 Service Loader Mediator Specification] or the specification.
+
+ Provide-Capability: \
+ osgi.serviceloader; \
+ osgi.serviceloader=org.gjt.xpp.XmlPullParserFactory
+
+This will make the Service Loader service available to Service Loader _consumers_ but it will not do anything unless there is a _registrar_ present. So we need to add a requirement for the OSGi extender `osgi.serviceloader.registrar`:
+
+ Require-Capability: \
+ osgi.extender; \
+ filter:="(&(osgi.extender=osgi.serviceloader.registrar)"
+
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/310-licenses.md b/_tutorial_wrap/310-licenses.md
new file mode 100644
index 0000000..4584eaf
--- /dev/null
+++ b/_tutorial_wrap/310-licenses.md
@@ -0,0 +1,55 @@
+---
+title: Licenses
+summary: Wrapping creates a copy of other peoples work, we need to take a look at how to attribute their work.
+layout: prev-next-collection
+---
+
+We've copied someone else's byte codes ... This puts an obligation on you to obey their license(s).We should add a `Bundle-License` header to the manifest.
+
+The primary license is of course DOM4J. This took some effort but they use a [BSD style license].
+The following licenses were found:
+
+* `dom4j` – A [BSD style license]
+* `relaxng` – A BSD license with an exception for the `org.relaxng.datatype.helpers.DatatypeLibraryLoader`
+* `pull-parser` – [Indiana University License](http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/LICENSE.txt)
+
+The format of the Bundle-License header is:
+
+ Bundle-License ::= '<>' | ( license ( ',' license ) * )
+ license ::= name ( ';' license-attr ) *
+ license-attr ::= description | link
+ description ::= 'description' '=' string
+ link ::= 'link' '='
+
+
+We therefore should add a license like:
+
+ Bundle-License: \
+ https://opensource.org/licenses/BSD-2-Clause; \
+ description='For DOM4J and relax NG'; \
+ link='', \
+ http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/LICENSE.txt; \
+ description='Pull Parser'; \
+ link='http://www.extreme.indiana.edu/xgws/xsoap/xpp/download/PullParser2/LICENSE.txt', \
+ 'Thai Open Software Center'; \
+ description='Exception for relaxng'; \
+ link='tosc-license.txt'
+
+Since we refer to the local file `tosc-license.txt` we need to copy this on the file system and then include it in the bundle:
+
+ -includeresource: \
+ @pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION, \
+ @pull-parser__pull-parser-2.1.10.jar!/META-INF/services/*, \
+ tosc-license.txt
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/320-readme.md b/_tutorial_wrap/320-readme.md
new file mode 100644
index 0000000..97bf9bf
--- /dev/null
+++ b/_tutorial_wrap/320-readme.md
@@ -0,0 +1,46 @@
+---
+title: README
+summary: Be a good citizen and add a README to your bundle so other people don't have to guess
+layout: prev-next-collection
+---
+
+We know, documenting is a pita ... However, you do appreciate it yourself when you don't have to guess yourself what a bundle does so why no spend 5 mins providing some proper documentation?
+
+In each OSGi enRoute project you will find a `readme.md` file. It is strongly suggested that you edit this file and include it in the `-includeresource` instruction. An option of this instruction allows you to process any bnd macros. So lets add the following description in `readme.md`:
+
+ # OSGI ENROUTE EXAMPLES WRAPPING DOM4J ADAPTER
+
+ ${Bundle-Description}
+
+ This bundle was constructed from the following JARs:
+
+ ${-buildpath}
+
+ Exports are: ${exports}
+
+ You can find this project on https://github.com/osgi/osgi.enroute.examples/${p}
+
+ This bundle is version ${versionmask;===;${Bundle-Version}} and was build on ${tstamp}
+
+
+
+To pre-process this file for macros, add curly braces ('{' and '}') around the resource.
+
+ -includeresource: \
+ @pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION, \
+ @pull-parser__pull-parser-2.1.10.jar!/META-INF/services/*, \
+ tosc-license.txt, \
+ {readme.md}
+
+
+[DOM4J]: http://jpm4j.org/#!/p/org.jdom/jdom
+[JPM4J]: http://jpm4j.org/
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
\ No newline at end of file
diff --git a/_tutorial_wrap/400-conclusion.md b/_tutorial_wrap/400-conclusion.md
new file mode 100644
index 0000000..c9e7f24
--- /dev/null
+++ b/_tutorial_wrap/400-conclusion.md
@@ -0,0 +1,81 @@
+---
+title: Conclusion
+summary: Show the final bnd.bnd file
+layout: prev-next-collection
+---
+
+You can look at the (archived) [osgi.enroute.examples.wrapping.dom4j.adapter] project for the final result. As a summary, this is the resulting bnd file:
+
+ #
+ # OSGI ENROUTE EXAMPLES WRAPPING DOM4J ADAPTER BUNDLE
+ #
+
+ version-dom4j = 1.6.1
+ version-relaxng = 1.0.0
+ version-gjt = 2.1.10
+
+ Bundle-Version: 1.6.1.${tstamp}
+ Bundle-Description: Wraps DOM4J for OSGi, including the primary dependencies
+ Bundle-Copyright: OSGi enRoute
+ Bundle-Vendor: OSGi Alliance
+
+
+ Export-Package: \
+ org.dom4j.*;version=${version-dom4j}, \
+ org.relaxng.datatype;version=${version-relaxng}, \
+ org.gjt.xpp;version=${version-gjt}
+
+ Private-Package: \
+ org.gjt.xpp.*
+
+ Provide-Capability: \
+ osgi.contract; \
+ osgi.contract=DOM4J; \
+ uses:="${exports}"; \
+ version:List="1.0"
+
+ Import-Package: \
+ com.sun.msv.datatype.*; resolution:=optional, \
+ !org.xmlpull.*, \
+ *
+
+
+ -includeresource: \
+ @pull-parser__pull-parser-2.1.10.jar!/PullParser*_VERSION, \
+ tosc-license.txt, \
+ {readme.md}
+
+ -conditionalpackage: \
+ !javax.*, \
+ !org.xml.*, \
+ !org.w3c.*, \
+ !org.ietf.jgss, \
+ !org.omg.*, \
+ !com.sun.*, \
+ !org.jaxen.*, \
+ !org.xmlpull.*, '\
+ *
+
+ -buildpath: \
+ org.jvnet.hudson.dom4j__dom4j;version=1.6.1.hudson-3,\
+ xmlpull__xmlpull;version=1.1.3.4d_b4_min,\
+ pull-parser__pull-parser;version=2.1.10,\
+ jaxen;version=1.1.6, \
+ net.java.dev.msv.core;version=2013.6.1,\
+ net.java.dev.msv.xsdlib;version=2013.6.1,\
+ relaxngDatatype__relaxngDatatype;version=20020414.0
+
+ -testpath: \
+ osgi.enroute.junit.wrapper;version=4.12
+
+With OSGi enRoute, you automatically get the Gradle build. However, notice that this file can easily be used in a Maven build with a few adaptations.
+
+[-conditionalpackage]: http://bnd.bndtools.org/instructions/conditionalpackage.html
+[blog]: http://njbartlett.name/2014/05/26/static-linking.html
+[133 Service Loader Mediator Specification]: http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
+[semanticaly versioned]: http://bnd.bndtools.org/chapters/170-versioning.html
+[135.3 osgi.contract Namespace]: http://blog.osgi.org/2013/08/osgi-contracts-wonkish.html
+[BSD style license]: http://dom4j.sourceforge.net/dom4j-1.6.1/license.html
+[supernodes of small worlds]: https://en.wikipedia.org/wiki/Small-world_network
+[OSGiSemVer]: https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
+[osgi.enroute.examples.wrapping.dom4j.adapter]: https://github.com/osgi/osgi.enroute.examples/tree/485624f6cb66df91f668d6eb9a5c8e491312c8c4/osgi.enroute.examples.wrapping.dom4j.adapter
diff --git a/_tutorial_wrap/img/container.png b/_tutorial_wrap/img/container.png
new file mode 100644
index 0000000..b3da1dd
Binary files /dev/null and b/_tutorial_wrap/img/container.png differ
diff --git a/_tutorial_wrap/img/content.png b/_tutorial_wrap/img/content.png
new file mode 100644
index 0000000..80ec985
Binary files /dev/null and b/_tutorial_wrap/img/content.png differ
diff --git a/_tutorial_wrap/img/contents-2.png b/_tutorial_wrap/img/contents-2.png
new file mode 100644
index 0000000..6e38a88
Binary files /dev/null and b/_tutorial_wrap/img/contents-2.png differ
diff --git a/_tutorial_wrap/img/contents-3.png b/_tutorial_wrap/img/contents-3.png
new file mode 100644
index 0000000..ef902e8
Binary files /dev/null and b/_tutorial_wrap/img/contents-3.png differ
diff --git a/_tutorial_wrap/img/contents-4.png b/_tutorial_wrap/img/contents-4.png
new file mode 100644
index 0000000..33aa4c1
Binary files /dev/null and b/_tutorial_wrap/img/contents-4.png differ
diff --git a/_tutorial_wrap/img/deps.png b/_tutorial_wrap/img/deps.png
new file mode 100644
index 0000000..f731997
Binary files /dev/null and b/_tutorial_wrap/img/deps.png differ
diff --git a/_tutorial_wrap/img/history.png b/_tutorial_wrap/img/history.png
new file mode 100644
index 0000000..82bbe28
Binary files /dev/null and b/_tutorial_wrap/img/history.png differ
diff --git a/_tutorial_wrap/img/imports-bundle.png b/_tutorial_wrap/img/imports-bundle.png
new file mode 100644
index 0000000..1d50bd3
Binary files /dev/null and b/_tutorial_wrap/img/imports-bundle.png differ
diff --git a/_tutorial_wrap/img/imports-clean.png b/_tutorial_wrap/img/imports-clean.png
new file mode 100644
index 0000000..a15858f
Binary files /dev/null and b/_tutorial_wrap/img/imports-clean.png differ
diff --git a/_tutorial_wrap/img/imports-missing-xmlpull.png b/_tutorial_wrap/img/imports-missing-xmlpull.png
new file mode 100644
index 0000000..e8c769f
Binary files /dev/null and b/_tutorial_wrap/img/imports-missing-xmlpull.png differ
diff --git a/_tutorial_wrap/img/imports-msv-optional.png b/_tutorial_wrap/img/imports-msv-optional.png
new file mode 100644
index 0000000..ee90dc9
Binary files /dev/null and b/_tutorial_wrap/img/imports-msv-optional.png differ
diff --git a/_tutorial_wrap/img/imports-msv.png b/_tutorial_wrap/img/imports-msv.png
new file mode 100644
index 0000000..2900153
Binary files /dev/null and b/_tutorial_wrap/img/imports-msv.png differ
diff --git a/_tutorial_wrap/img/jar-editor.png b/_tutorial_wrap/img/jar-editor.png
new file mode 100644
index 0000000..802e7aa
Binary files /dev/null and b/_tutorial_wrap/img/jar-editor.png differ
diff --git a/_tutorial_wrap/img/program.png b/_tutorial_wrap/img/program.png
new file mode 100644
index 0000000..f8ae279
Binary files /dev/null and b/_tutorial_wrap/img/program.png differ
diff --git a/_tutorial_wrap/img/revsion.png b/_tutorial_wrap/img/revsion.png
new file mode 100644
index 0000000..5069a58
Binary files /dev/null and b/_tutorial_wrap/img/revsion.png differ
diff --git a/_tutorial_wrap/img/search.png b/_tutorial_wrap/img/search.png
new file mode 100644
index 0000000..26eff40
Binary files /dev/null and b/_tutorial_wrap/img/search.png differ
diff --git a/_tutorial_wrap/img/sunmsv.png b/_tutorial_wrap/img/sunmsv.png
new file mode 100644
index 0000000..11ec1c0
Binary files /dev/null and b/_tutorial_wrap/img/sunmsv.png differ
diff --git a/_videos/chuck-boecking-persistence.md b/_videos/chuck-boecking-persistence.md
new file mode 100644
index 0000000..0e476db
--- /dev/null
+++ b/_videos/chuck-boecking-persistence.md
@@ -0,0 +1,12 @@
+---
+title: OSGi Enroute Base Tutorial Demonstration with Persistence
+layout: prev-next-collection
+summary: An example project that demonstrates the use of the OSGi enRoute REST API
+---
+
+An example project that demonstrates the use of the OSGi enRoute REST API from Chuck Boecking (ERP Academy). If you checkout the examples repository, then you can easily run the code and see how the REST API works.
+
+[See more ...](https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.rest.application)
+
+
+
diff --git a/_videos/osgi-ce-2015-iot-contest.md b/_videos/osgi-ce-2015-iot-contest.md
new file mode 100644
index 0000000..672fa4c
--- /dev/null
+++ b/_videos/osgi-ce-2015-iot-contest.md
@@ -0,0 +1,15 @@
+---
+title: OSGi Community Event 2015 IoT Contest Video
+layout: prev-next-collection
+summary: A short video showing the emulator and the train used during the OSGi CE 2015 IoT Contest
+---
+
+At the OSGi CE 2015 at the EclipseCon in Ludwigsburg, Germany, the OSGi Alliance held an IoT contest. Using OSGi enRoute, contestants could use an SDK to write either a Train or Track Manager. These bundles could be tested with a software emulator. During the Community Event, the Alliance installed an actual Lego train that was controlled by a cloud server and multiple Raspberry Pi's. The winner was Ghislain Nadeau and it is his bundle controlling the train in the video. Congratulations!
+
+
+
+We are planning to move the contest [SDK to a tutorial][1].
+
+
+
+[1]: /trains/200-architecture.html
\ No newline at end of file
diff --git a/_videos/paul-fraser-comev02016.md b/_videos/paul-fraser-comev02016.md
new file mode 100644
index 0000000..b074bdc
--- /dev/null
+++ b/_videos/paul-fraser-comev02016.md
@@ -0,0 +1,10 @@
+---
+title: Paul Fraser's Community Event talk about OSGi enRoute
+layout: prev-next-collection
+summary: Paul Fraser's promotion of his OSGi Community Event talk about OSGi enRoute
+---
+
+Paul Fraser's promotion of his OSGi Community Event talk about OSGi enRoute
+
+
+
diff --git a/img/repositories-overview.png b/img/repositories-overview.png
new file mode 100644
index 0000000..b2e5a4a
Binary files /dev/null and b/img/repositories-overview.png differ