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
Let’s start with the first non-JVM dependency:
com.sun.msv.datatype. We can search this on JPM4J with the
p: modifier. You can find all JARs on JPM4J that contain
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 and add it to our build path.
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: \ org.jvnet.hudson.dom4j__dom4j;version=1.6.1.hudson-3,\ net.java.dev.msv.xsdlib;version=2013.6.1
And if you go to the
Content tab you will see that the
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!)
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.