The example that you’ve just given is an excellent candidate for splitting into
two bundles. Small bundles are not a sign of bad code, just well-purposed code.
Having the servlet in there is a smell because it’s unrelated to the actual
purpose of the bundle (namely providing a ready service).
I generally agree about optional packages in most cases I simply avoid them.
In some rare cases they are not so bad though. For example in felix system
ready we used it to provide a servlet if the servlet spec is available. DS
helps nicely with this so we did not have to handle
One of the big challenges with optional imports is that they are so rarely
actually optional, and that they end up not being wired to you in future if the
dependency becomes available as a result of a later bundle installation
Every time I see an optional import it tells me that the bundle has
I am currently looking into improving the OSGi setup of bundles.
For package exports I have found the package-info.java to be the best
practice (see below):
@org.osgi.annotation.versioning.Version("1.0.0")
@org.osgi.annotation.bundle.Export
package my.package;
Imports are normally computed
