Java Reference
In-Depth Information
You'll notice we didn't add a
<Bundle-Blueprint>
element. Although there's nothing
stopping you adding this header, the bundle plug-in is smart enough to hunt out Blue-
print files and automatically add the
Bundle-Blueprint:
headers for you.
The
org.osgi.service.blueprint
dependency
If you look at the manifest generated for you by the bundle plug-in, you'll see an extra
imported package,
org.osgi.service.blueprint
. Where did this import come
from? When the Maven bundle plug-in detects that your bundle uses Blueprint, it will
automatically add that package dependency. Although this package doesn't include
any code, the Blueprint specification encourages Blueprint bundles to import it to
ensure that Blueprint is available in their runtime environment. (The specification
also insists that Blueprint implementations must export this package.) If you need
your bundle to run in non-Blueprint environments too, you can make the package op-
tional by specifying it explicitly in your pom:
<Import-Package>
org.osgi.service.blueprint;resolution:=optional
</Import-Package>
If you're using code-first development, you've got a lot of build tools open to you. You
can use bnd on its own, you can use it in combination with Ant, or you can use the
powerful Maven build plug-in. If you're doing manifest-first development, you have a
similar choice between Ant and Maven. Several tools allow manifest-first building
using Ant, although most involve some degree of duplication of information with the
IDE
. There's also a nice set of Maven plug-ins that neatly share information with the
Eclipse
PDE
IDE
.
8.2.3
Ant and Eclipse PDE
With manifest-first development, one of the main challenges of building an
OSG
i bun-
dle vanishes; there's no need for the tools to work out a manifest, because you've
already written one. But it's still necessary to work out a classpath for compiling. Ide-
ally, this classpath should be the same as the one used by the Eclipse
IDE
, without hav-
ing to duplicate it between
IDE
and command-line environments. For bonus points,
the compile stage should pay attention to the manifest and only allow imported pack-
ages onto the compile-time classpath.
THE ECLIPSE HEADLESS BUILD
It turns out that this is a challenging set of requirements. The only Ant tool that fully
satisfies them is a miniaturized headless version of the
IDE
.
Despite running without a
GUI
, the Eclipse headless build is fairly heavyweight.
Even projects that want to take advantage of Eclipse's metadata often try to build with-
out the direct dependency on the Eclipse runtime. The Eclipse headless build is also
fairly inflexible, so integrating extra build steps like coverage instrumentation or cus-
tom packaging can be painful.
