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.
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.
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.
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
Search WWH ::

Custom Search