Why OSGi Qualifiers Aren’t Working

13. April, 2012

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.

When Eclipse Won’t Start

13. April, 2012

There can be a couple of reasons why Eclipse refuses to start: Corrupted workspace, broken plugins or conflicting plugins. This blog post is about the last category.

How do you know that you’re affected? Start Eclipse with the command line option -debug. If there is a huge gap between “Time to load bundles” and “Starting application”, you’re on.

Start Eclipse in a debugger and set a breakpoint in org.eclipse.osgi.internal.module.ResolverImpl.findBestCombination(ResolverBundle[], ResolverConstraint[][], int[], List<ResolverConstraint>).

The interesting information is in the variable bestConflictBundles. This is basically a list of bundles that cause some kind of trouble. Usually, this is a bundle which has the singleton flag set but of which are two versions in the plugins folder (or in the plug-in list, if you started Eclipse from another instance of itself).

If you started Eclipse from itself (using a launch configuration), the solution is to open the “Debug Configurations…” editor, select the “Plug-ins” tab:

This tab has several interesting options: You can type (part of) a plug-in ID into the filter field to narrow down the huge list. If the list isn’t active, select “Launch with: plug-ins selected below only” above.

That way, if you want to disable all of BIRT, type “birt” and then click “Deselect all” to the right.

Next stop is the “Validate Plug-ins” button in the bottom left. This opens a dialog with all the problems the current selection has. This dialog isn’t modal! That means you can keep it open while you (de-)select plugins from the list. If your screen is big enough, you can move it so you can see the list and the “Validate” button. That way, you never need to close the dialog.

Otherwise, Alt+V is your friend.

In my example, the org.eclipse.jpt.jpa.db plug-ins cause trouble. As you can see, I pulled them out with a short text in the filter. Now, I can get rid of them with a single click on “Deselect all”. Validate … okay, things for worse.

But I don’t need anything from JPT for my tests, so I get rid of the whole lot. Validate … “No problems were detected.”


%d bloggers like this: