Nepomuk Version Management

Golden Rules

  • Only do one change at a time
  • after each change, checkout the EclipseTargetPlatform in a clear workspace and test if the change broke something

OSGi and Java packages Versions Managing

Developing using the OSGI framework makes it simpler for us to handle the problem of incopabilities between plugins in different versions.

Every time we commit new bundles to the eclipse target platform, this is a new release of the plugin. Version numbers are increased then.

Howto Increase version numbers:

  • we develop version 0 of a plugin X - the version number is 0.0.0.snapshot. (the name "snapshot" is inspired by Maven2 and will trigger the right semantics in Maven-aware developers). You write this number into the plugin manifest /META-INF/manifest.mf

Note: we have to use .snapshot instead of -snapshot because of OSGI restrictions.

  • we work on the snapshot version until it is stable and ready for release.
  • the snapshot is renamed to version 0.0.0. A commit is made to the bundle and to the EclipseTargetPlatform
  • a tag in SVN is done to mark this version (suggested name: /tags/versions/org.semanticdesktop.X_0.0.0)
  • after this, the bundle's version number is immediately increased to 0.0.1.snapshot and commited to SVN
  • the developers work on this snapshot version until its fixed.
  • repeat...

New versions of OSGi packages

Updating your plugin in the ETP:

It is very simple:

There are five places to put a plugin in the ETP folder: (there is also an all folder, but this does not contain any plugins in itself) 

eclipse32/  	- built-in eclipse plugin, do not change
external/ 	- external dependencies, i.e. apache-commons, jaxb, etc.
server/  	- our own plugins - only used in the client
client/ 	- our own plugins only used in the server
shared/		- shared between server and client

All existing plugins have already been placed somewhere, so usually just put the new version where the old one is.

However, note that when updating the ETP you essentially make a "mini-release", therefore you should update the version number at the same time. My workflow goes like this:

  • Plugin has some version number (in METAINF.MF) - this ends in an odd number say 1.3
  • Make changes to this plugin, when ready to release, commit all changes.
  • Set version number to even number, i.e. 1.4
  • Export plugin, replace old myservice-1.2.jar with new myserver-1.4.jar
  • Now close all projects, apart from .product, reload ETP, run the product to make sure all is ok with your new ETP.
  • Now COMMIT both the ETP and the new version number in the plugin.
  • Now change plugin version number again, to a new odd number: i.e.: 1.5
  • Commit the changed version number again.

This way we can know that the code in ETP corresponds to a single state of the code, namely the one where it was committed with the even version number.

Version numbers in OSGi features

The plugins are bundled as OSGi features, multiple plugins are added to a feature to express that they are shipped together.

In the feature.xml files, version management can easily break. Therefore, we reference plugin version 0.0.0.

Releases of the Nepomuk OSGI System

When to make a release?

how to freeze version numbers on bundles?

compability checks, JUnit tests, verifications... ?

Building Eclipse Plugins Headless

This tutorial may help: