If you don’t understand how OSGi bundles get versions: You’re not alone.
On paper, the rules are pretty simple and straightforward.
In reality, the rules are broken by many Eclipse bundles because the tools don’t help to enforce them (Alex Blewitt wrote two great posts about that: “Why OSGi qualifiers aren’t working” and “Using Humans to solve a Tooling problem“). It’s not a rare problem either. Alex found 10% of the bundles got a new qualifier but didn’t actually change. That doesn’t take bundles into account which did change but the version wasn’t bumped.
When I started on an automated converter to turn Eclipse bundles to Maven artifacts, I hit the same problems. Some bundles get rebuild for no apparent reason, some have changes but the version wasn’t bumped.
This causes some problems. First of all: Which of those two qualifiers is “bigger”? ”v20120119-1537″ or “xx-20120301-1000-e37-RELEASE”?
And if you think that’s probably a mistake: That’s the qualifier for org.eclipse.jdt.core.source. It’s one of the core bundles for Eclipse. If even the JDT people don’t get it right, there isn’t much hope.
When building something with Maven, you have something similar: SNAPSHOT versions. But unlike Eclipse,
- Maven forces you to drop the SNAPSHOT when you build a release
- Maven replaces the string “SNAPSHOT” in the version with a build timestamp. This gives a consistent version scheme.
- There are tools that check for SNAPSHOT versions
- Maven can’t mix SNAPSHOT and releases in a repository (so you’re less likely to accidentally pollute your build or, worse, the build of someone else).
Unfortunately, OSGi have abandoned -SNAPSHOT versions for R5.
But maybe we can fix the problem on the Eclipse side. If you care, support Bug 376718 - Strip qualifiers for release builds.
Tagged: Eclipse, OSGi
