To put a generic library – e.g. client libraries for our services, or common stuff like the link rewriter – into the TextGridLab, the following steps are neccessary:
- Make the library an OSGi bundle (using
maven-bundle-plugin) and deploy it to a Maven repository
- Aggregate the library into an Eclipse feature, and put it into a p2 repository. We use the
textgridlab-dependenciesproject for that.
- Depend on feature in an Eclipse-only feature or the product, and depend on the bundle or its packages in your bundle.
There are some caveats in each of the steps.
Making your library an OSGi bundle
In principle, your library can be OSGified by adding specific metadata to its Manifest file. There is a Maven plugin, the maven-bundle-plugin, created in the Apache Felix project and using the
bnd bundling tool, that is able to auto-generate the metadata for you. There are two alternative ways to use this plugin:
- define a packaging type of
bundlefor your project
- leave the packaging type
jar, but add an execution to your build that calls the bundle plugin's
manifestgoal to manipulate the bundle manifest.
You should avoid version 2.3.5 of the bundle plugin since it collides with generating source jars. Both earlier and later versions are fine, we have not yet encountered any specific trouble with version 2.4.0.
Maven vs. OSGi version
Your OSGified bundle will have two versions, and this is bound for trouble since the versioning systems are fundamentally different:
- a Maven version typically consists of three dot-separated numeric parts with an optional
SNAPSHOTwill be replaced with a timestamp when you deploy the snapshot to a repository, you can still reference the latest snapshot using the version string
1.2.3-SNAPSHOT. A released version does not have a suffix, so
- an OSGi version typically consists of four segments. In Eclipse and Tycho, the last segment can be specified as
qualifierin the source, which will be replaced by a timestamp (or an arbitrary override) during build. It is not possible to specify a literal
qualifierin a version dependency, however it is not customary to specify four-component-version numbers in dependency, typically a dependency on
1.2.3will take any (= usually the newest available) version starting with 1.2.3.
There are different semantics than with the maven SNAPSHOT for OSGi versions: