Java Reference
In-Depth Information
more likely you'd want to move the generic parts of it up to a parent pom. Almost any-
thing that can go into a bnd file can be added—in
XML
form—to the bundle plug-in
configuration, and the cautions that apply to writing bnd files also apply to configur-
ing the bundle plug-in.
TAKING ADVANTAGE OF DEFAULTS
The Maven bundle plug-in uses the information available elsewhere in the pom file to
provide some nice defaults. If you don't specify the bundle symbolic name, the plug-in
will construct it from the group
ID
and default
ID
. In general, it will be
${pom.groupId}.${pom.artifactId}
, but overlaps between the group
ID
and artifact
ID
will be stripped out. Maven will automatically use the artifact
ID
and version for the
JAR
name, but it's good
OSG
i practice to use the symbolic name (and version) for the
JAR
names. Therefore, we suggest ensuring that your artifact
ID
matches your intended
bundle symbolic name. For example, to get a bundle symbolic name of
fancyfoods.api
and a
JAR
name of fancyfoods.api-1.0.0.jar, choose an artifact
ID
of
fancyfoods.api
and
a group
ID
of
fancyfoods
.
The bundle version will be set to the module version. Similarly, the bundle name,
description, and license will all be taken from ones specified elsewhere in the pom.
The bundle plug-in also overrides some of the more counterintuitive bnd
defaults for what's included in and exported by the bundle, because it's able to dis-
tinguish between your local Java source and the binaries on your classpath. It
assumes that you do want to export packages you provided the source code for, but
don't want to export all the other packages on your classpath. Packages containing
impl
or
internal
in the name won't be exported. Recent versions of the bundle
plug-in default
<Private-Package>
to include classes in the module, rather than the
empty default you get with raw bnd.
WARNING: THE IMPORTANCE OF DOUBLE-CHECKING
As with plain bnd, it's a good
idea to validate your configuration of the bundle plug-in by having a look in the
bundle that comes out and making sure the manifest is what you hoped for, and
there aren't too many or too few classes packaged into the
JAR
.
You may find that, with bundles that are using service dependencies instead of pack-
age dependencies, even the bundle plug-in's defaults are too generous and you'll
need to restrict the exports further. In listing 8.2, they're listed explicitly. Versions will
be inferred from package-info files, as we discussed in section 8.2.1.
ENTERPRISE OSGI AND THE BUNDLE PLUG-IN
You can also add any other custom headers you need as
XML
elements. This enables
enterprise
OSG
i headers like
Meta-Persistence:
to enable container-managed
JPA
, or
Bundle-Blueprint:
file to point to a Blueprint file.
To see how the nondefault headers work in a pom, let's have a look at the pom file
for the persistence bundle. This is a more complex pom than the
API
pom, because
the persistence bundle has a Blueprint configuration and dependencies on other
