Moving toward bundles - OSGi in Action - page 193

Alternatively, you can use the domain of the project that distributes the JAR file. Here,
the domain is http://kxml.sourceforge.net/kxml2/ :

Bundle-SymbolicName: net.sourceforge.kxml.kxml2
Or if Maven ( http://maven.apache.org/ ) project metadata is available, you can use
the Maven groupId + artifactId to identify the JAR file:

Bundle-SymbolicName: net.sf.kxml.kxml2
Sometimes, you may decide on a name that doesn't correspond to a particular pack-
age or distribution. For example, consider two implementations of the same service
API provided by two different bundles. OSG i lets you hide non-exported packages, so
these bundles can have an identical package layout but at the same time provide dif-
ferent implementations. You can still base the symbolic name on the main top-level
package or the distribution domain, but you must add a suffix to ensure that each
implementation has a unique identity. This is the approach that the Simple Logging
Facade for Java ( SLF4J ; www.slf4j.org/ ) project used when naming its various logging
implementation bundles:

Bundle-SymbolicName: slf4j.juli
Bundle-SymbolicName: slf4j.log4j
Bundle-SymbolicName: slf4j.jcl
If you're wrapping a third-party library, you may want to prefix your own domain in
front of the symbolic name. This makes it clear that you're responsible for the bundle
metadata rather than the original third party. For example, the symbolic name for the
SLF4J API bundle in the SpringSource Enterprise Bundle Repository ( www.spring-
source.com/repository/app/ ) clearly shows that it was modified by SpringSource and
isn't an official SLF4J JAR :

All of these
bundles export
org.slf4j.impl

Bundle-SymbolicName: com.springsource.slf4j.api
Don't worry too much about naming bundles—in the end, you need to give each bun-
dle a unique enough name for your target deployment. You're free to rename your
bundle later if you wish, because by default the framework wires import packages to
export packages regardless of bundle symbolic names. It's only when someone uses
Require-Bundle (see section 5.3) that consistent names become important. That's
another reason why package dependencies are preferred over module dependencies:
they don't tie you to a particular symbolic name forever.

CHOOSING A VERSION
After you've decided on a symbolic name, the next step is to version your bundle.
Determining the Bundle-Version is more straightforward than choosing the symbolic
name, because pretty much every JAR file distribution is already identified by some
sort of build version or release tag. On the other hand, version-numbering schemes
that don't match the recognized OSG i format of major . minor . micro . qualifier must be con-
verted before you can use them. Table 6.1 shows some actual project versions and
attempts to map them to OSG i.