This website and its associated repositories, are deprecated and no longer supported by the OSGi Alliance. Please visit https://enroute.osgi.org for the latest supported version of OSGi enRoute.
This enRoute v2 archive site is kept for those who do not intend to use the latest version of OSGi enRoute. If you are new to OSGi enRoute, then please start with the latest OSGi enRoute.
If we inspect list of included packages we find that
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:
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
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.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
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.)