Building bundles - OSGi in Action - page 519

An import version of 1.5.8 using this policy maps to a version range of [1.5,2) . If you
find all these similar brackets confusing, remember that bnd lets you mix bracket
types, so you can always rewrite this last policy more clearly:

-versionpolicy: [$<version;==;$(@)>,$<version;+;$(@)>)

A.1.6 Mending split packages

As you saw back in chapter 6, when you're modularizing legacy applications, you may
encounter the thorny issue of split packages, where two different JAR s contain the
same package but with different contents. Bnd warns you when it detects split pack-
ages, but it still creates the bundle. These warnings can be irritating if you already
know about (and don't mind) the split package. Indeed, you may be creating this bun-
dle in order to merge the different parts together. To remove these warnings, add the
following package attribute to any known split packages:

Private-Package: org.foo.bean;-split-package:=merge-first
This tells bnd to silently merge the contents of the org.foo.bean package together
but not overwrite existing entries if there's any overlap. You can also choose not to
perform any merging by using the ;-split-package:first attributes.
You now know the various headers, directives, and macros available to us when
building bundles with bnd in Ant, but what if you're using another system, such as
Maven? Do you have to learn yet another syntax, or is there a way to reuse your exist-
ing knowledge of bnd?

A.2 Building with Maven

You saw in chapter 6 how easy it is to take an existing Ant-based project and migrate it
to OSG i with bnd. But what if you use Maven? Maven ( http://maven.apache.org ) is
another popular build tool from Apache that also uses XML to describe builds, but
this time the description is declarative rather than procedural. Instead of listing the
steps required to build a JAR (also known as an artifact ), you list the packaging as jar
in the project XML .
Maven favors convention over configuration; follow the Maven way, and you can
keep your XML relatively lean and uncomplicated. The problem is when you need to
do something special outside of the normal Maven build process. You can end up with
pages of XML detailing each step of your customized build.
How well does OSG i fit with Maven? Will you need pages of configuration to assem-
ble your bundle?

A.2.1 Introducing the maven-bundle-plugin

The Maven build process is extended by adding plugins to projects. Maven plugins
contain one or more Maven plain old Java objects (mojos), each of which represents a
specific goal, such as assembling a JAR from classes and resources. A well-written
plugin complements the Maven process and requires minimal setup by following the
convention-over-configuration mantra.