Every technology can enable questionable or even destructive uses. What follows is one that OSGI enables.

From that perspective, this screenshot is perfect OSGI anti-pattern. OSGI going to the dark side. (No, it has nothing to do with groovy or the plugin shown)

Yes Mildred, OSGI offers java developers like myself a chance to get out of jar hell, if that's something that is required on a project. Very good stuff.

Like anything else, it can be abused and mis-used. Before I explain how the above screenshot evidences that, let me give you the 15 second analogy first: 

Mis-use of Exception Handling - As An Analogy:

  • Developer too busy adding features to test app and fix bugs.
  • User clicks on some combination that developer did not anticipate
  • User Interface returns a screen full of stack trace. User has no possible idea what to do with this information.

Not good. This user is getting pimped. He does not care about stack trace, he wants to use the app. The developer is abusing exception handling, or at least from this perspective.

I've done it, and you've probably done it too, if you are a veteran developer who has had alpha and beta versions of apps out there. Bad practice, regardless.

Mis-use of OSGI In The Above Example:

OSGI allows the developer to write technology such as eclipse foundation's p2 which assembles products from OSGI jars, literally on the fly. Very cool. Seriously neat stuff.

What is totally cool about that is you can pimp the user every bit as effectively as throwing up a page of stack trace in a UI. Take the screenshot above. The user is offered a list of choices, then when he makes those choices he's told "no freaking way". He may continue trying infinite combinations, in an endless loop. Sometimes he may even succeed. Or not.

Then to make it worse, he's offered the OSGI equivalent of stack trace. Not that you would want to, but in the details box at the bottom, you can copy and paste from it and get hundreds of lines of information that looks like this:

Cannot complete the request.  See the details.
Unsatisfied dependency: [org.codehaus.groovy17.feature.feature.group 2.0.1.20100319-1100-e35-RELEASE] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.equinox.p2.metadata.generator/1.0.100
Unsatisfied dependency: [org.codehaus.groovy16.feature.feature.group 2.0.1.20100319-1100-e35-RELEASE] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.equinox.p2.metadata.generator/1.0.100
Cannot find a solution where both "org.eclipse.equinox.p2.metadata.generator [1.0.4.v20081217]" and "org.eclipse.equinox.p2.metadata.generator 1.0.100" are satisfied.
Unsatisfied dependency: [org.codehaus.groovy.alltests.feature.feature.group 2.0.1.20100319-1100-e35-RELEASE] requiredCapability: org.eclipse.equinox.p2.iu/org.codehaus.groovy.alltests.feature.feature.jar/[2.0.1.20100319-1100-e35-RELEASE,2.0.1.20100319-1100-e35-RELEASE]
[yada yada this is just first of several hundred lines of errors]

Again?

I can't guess how many times I've tried to install a plugin into eclipse in the last couple years and run into a brick wall like this one, above. Ever since this p2 thing was rolled out years ago. You can blame me for trying out different versions of plugins - but I cannot be the only one that has lost a lot of productivity to this particular design decision.

To be fair, things are getting better. For example the above problem was fixed by getting a newer version of eclipse and trying again. But that completely sidesteps my point, which is that it's a complete abuse of OSGI to offer users to invalid choices, and then punish them with the equivalent of stack trace, when they do.

My 2c