Navigation
RSS Feed
Recent blog posts
- 300 Times Faster On Your Graphics Card? - Your Java
- OSGi Players To Watch
- It's Easy To Succeed: 10 Years of JavaMUG
- When m2eclipse Goes South, Costs Mount Fast
- Martin Lippert Moves to SpringSource
- Why OSGi Deserves A Slow and Painful Death
- News From JavaOne Warmed My Heart
- Keeping Safe from Dangerous Fred the Developer
- Google Makes Serious Eclipse Tools Free!
- Try This to Juice Up Your User's Group!
May
6
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.100Unsatisfied 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.100Cannot 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
Actually I don't see what this post has got to do with OSGi. P2 is a repository manager and installation tool, which can install many kinds of artifacts, not just OSGi bundles. In this case it has decided that two of the things it has been asked to install are incompatible and cannot co-exist. That, together with the appalling error reporting, is p2's problem, not OSGi's.
But p2 is basically trying to do the right thing. Installing incompatible artifacts is bad.
In OSGi it is usually safe (though not very useful) to install incompatible versions of the same bundle. In "standard" Java you can put anything you like on your classpath without any of those pesky warnings or resolution problems.... you just get utterly screwed by the LinkageErrors, IncompatibleClassChangeErrors, NoSuchMethodErrors, etc, when you actually try to run it.
An exception, no. This is the explanation that is produced.
The analogy to exceptions is not very fair and is far from reflecting the reality. In fact the explanation results from the computation of the unsat core which is far from being a trivial problem (we are using SAT4J for this).
Now I agree that the presentation is sloppy, but despite some time bounded effort on this, we have not found a comprehensible way to present this information and are really opened to any ideas (see http://bugs.eclipse.org/261928).
As for OSGi abuse, I think we just follow the trend :), but we are working on limiting it.
In response to Neil Bartlett's comment - your point may be appropriate. In this case I'm equating the tool that was enabled by OSGI (p2) with OSGI itself, which may not be reasonable.
In response to both Neil and Pascal's comment, my point is that user experience trumps all other logic. It either works for the user or it doesn't. When the user is given choices that only lead to failure, that does not work. The logic that leads up to that moment is, at the point of failure, completely irrelevant. Failure is failure, and all other explanations and excuses are just that - useless explanations - to the user anyway.
The reason this is so important to clarify this as an anti-pattern is because OSGI offers us so many possibilities (like p2) that were not even thinkable before. Like any powerful tool, it can be used in beneficial, or not so beneficial ways.
Hmmm??? I encountered this obviously, because I'm here... but I didn't give up so easily.. The error seemed to me to say, "Look at the versioning." (no kidding), so I did. Ahh! That was the real issue "Incompatible Version", not that OSGI or P2 was an anti-patterns. I just screwed up. I tried to install the wrong version of Groovy here. Once I cut and pasted the correct site URL version of Groovy into the Plugin tool, bingo bango... it worked just fine no "Incompatible Version". Now I feel silly because I said something about this to a co-worker before all my ducks were in order.
Now Groovy has two versions, one for 3.4 and another for 3.5.
Silly me...
This gets to another point. Please pay attention here Eclipse guys, How about we label Galileo and Ganymede with the major/minor version numbers. I know what they are but sometimes we work tooo many hours and we simple do something silly.
Post new comment