Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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:

  1. Make the library an OSGi bundle (using maven-bundle-plugin) and deploy it to a Maven repository
  2. Aggregate the library into an Eclipse feature, and put it into a p2 repository. We use the textgridlab-dependencies project for that.
  3. 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 bundle for your project
  • leave the packaging type jar, but add an execution to your build that calls the bundle plugin's manifest goal 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 -SNAPSHOT suffix. SNAPSHOT will 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 1.2.3-SNAPSHOT1.2.3.
  • an OSGi version typically consists of four segments. In Eclipse and Tycho, the last segment can be specified as qualifier in the source, which will be replaced by a timestamp (or an arbitrary override) during build. It is not possible to specify a literal qualifier in a version dependency, however it is not customary to specify four-component-version numbers in dependency, typically a dependency on 1.2.3 will take any (= usually the newest available) version starting with 1.2.3.
    There are different semantics than with the maven SNAPSHOT for OSGi versions: 1.2.3.201312281305 > 1.2.3

 

  • No labels