Opening any pom.xml gets CNFE for IElementChangedListener by org.springframework.ide.eclipse.xml.namespaces_3.9.9.201905211834-CI-B2250
Closed this issue · 41 comments
I recently updated my Eclipse plugins, and I noticed that Spring IDE had some updates.
Today I'm finding that every time I try to open a pom.xml file, I get a "Multiple problems have occurred" dialog, with a detail of "An error has occurred. See error log for more details.
org/eclipse/jdt/core/IElementChangedListener". Even worse, when I dismiss the dialog, it just displays again. I tried many times to dismiss it, and it just redisplays. My only option is killing Eclipse.
When restarting Eclipse, the pom.xml file is still displayed, and an error dialog comes up saying "'Loading referenced grammars' has encountered a problem", with a detail of "An internal error occurred during: "Loading referenced grammars".
org/eclipse/jdt/core/IElementChangedListener".
When I dismiss this dialog, it does not reappear.
I've tested this sequence several times now.
In the error log, I see repeated instances of this stacktrace:
!ENTRY org.eclipse.jface 4 2 2019-05-28 15:11:48.411
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.NoClassDefFoundError: org/eclipse/jdt/core/IElementChangedListener
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:279)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:716)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:639)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:607)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:587)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:566)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:331)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:473)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:612)
at org.eclipse.wst.common.uriresolver.internal.URIResolverExtensionDescriptor.getResolver(URIResolverExtensionDescriptor.java:81)
at org.eclipse.wst.common.uriresolver.internal.URIResolverExtensionRegistry.getMatchingURIResolvers(URIResolverExtensionRegistry.java:166)
at org.eclipse.wst.common.uriresolver.internal.ExtensibleURIResolver.resolve(ExtensibleURIResolver.java:83)
at org.eclipse.wst.xml.core.internal.modelquery.XMLCatalogIdResolver.resolve(XMLCatalogIdResolver.java:94)
at org.eclipse.wst.xml.core.internal.modelquery.XMLModelQueryAssociationProvider.resolveGrammarURI(XMLModelQueryAssociationProvider.java:60)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.XMLAssociationProvider.resolveGrammarURI(XMLAssociationProvider.java:170)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.lookupOrCreateResolvedURI(CMDocumentManagerImpl.java:124)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.addCMDocumentReference(CMDocumentManagerImpl.java:206)
at org.eclipse.m2e.editor.xml.PomModelHandler$PomModelQueryAssociationProvider.getCMElementDeclaration(PomModelHandler.java:120)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.ModelQueryImpl.getCMElementDeclaration(ModelQueryImpl.java:118)
at org.eclipse.wst.xml.ui.views.contentoutline.XMLContentOutlineConfiguration$AttributeShowingLabelProvider.getAttributeToShow(XMLContentOutlineConfiguration.java:75)
at org.eclipse.wst.xml.ui.views.contentoutline.XMLContentOutlineConfiguration$AttributeShowingLabelProvider.getText(XMLContentOutlineConfiguration.java:142)
at org.eclipse.m2e.editor.xml.PomContentOutlineConfiguration$PomLabelProvider.getText(PomContentOutlineConfiguration.java:231)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.getText(WrappedViewerLabelProvider.java:99)
at org.eclipse.jface.viewers.WrappedViewerLabelProvider.update(WrappedViewerLabelProvider.java:148)
at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:144)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:946)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:120)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.ui.internal.JFaceUtil.lambda$0(JFaceUtil.java:47)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:176)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1025)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:478)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.ui.internal.JFaceUtil.lambda$0(JFaceUtil.java:47)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:176)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2160)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:840)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:818)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:604)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:766)
at org.eclipse.jface.viewers.AbstractTreeViewer.internalInitializeTree(AbstractTreeViewer.java:1586)
at org.eclipse.jface.viewers.TreeViewer.internalInitializeTree(TreeViewer.java:780)
at org.eclipse.jface.viewers.AbstractTreeViewer.lambda$1(AbstractTreeViewer.java:1571)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1448)
at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:363)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1409)
at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1565)
at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:282)
at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1686)
at org.eclipse.wst.sse.ui.internal.contentoutline.ConfigurableContentOutlinePage.setInput(ConfigurableContentOutlinePage.java:696)
at org.eclipse.wst.sse.ui.StructuredTextEditor.update(StructuredTextEditor.java:3199)
at org.eclipse.m2e.editor.pom.MavenPomEditor$MavenPomActivationListener.handleActivation(MavenPomEditor.java:1019)
at org.eclipse.m2e.editor.pom.MavenPomEditor$MavenPomActivationListener$1.run(MavenPomEditor.java:979)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3919)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3550)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1062)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:566)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:661)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
at org.eclipse.equinox.launcher.Main.run(Main.java:1476)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.core.IElementChangedListener cannot be found by org.springframework.ide.eclipse.xml.namespaces_3.9.9.201905211834-CI-B2250
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:460)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:153)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 85 more
As you can see, this is coming from something in the Spring IDE.
I was able to "fix" this problem by simply setting to the Eclipse configuration before I updated these plugins. That's obviously just a temporary workaround
What version of Eclipse patform? And what version of JVM are you running it with?
I've quickly tried the latest STS 3.9 snapshot build on Eclipse 4.11, running with JDK 1.8. I used the 'distribution build' not an installation from update sites. Installation from update sites can be flaky and its hard to know what kind of old stuff may be lingering in an Eclipse install that's gone through repeated 'updates' over a long time.
My guess is that either there is some old version of JDT bundle around in your setup, or it has something to do with running on a newer JDK (10, 11 ?). So I'll try next what happens with a more modern JDK.
Seems to be fine on JDK 11.0.2.
I'm on java-2019-03, currently with jdk 12.0.1. I saw this first with "1.8.0_152".
I suppose a possible mitigation strategy would be uninstalling all the relevant plugins and reinstalling them. I see three plugins that match "spring" in the list:
- Spring Boot Language Server Feature
- Spring IDE Boot Microservices Dash
- Spring Tool Suite 4 Main Feature
The interesting bit would rather be what version of jdt plugin is in your setup because the CNF exception is related to a class from JDT.
java.lang.NoClassDefFoundError: org/eclipse/jdt/core/IElementChangedListener
This kind of error usually means that either there's an old version of the corresponding bundle (one where this class did not exist yet), or also... could be something messed up with installed bundles conflicting with one another somehow causing the corresponding bundle to fail to be activated (making all its classes going missing, this kind of thing can happen, for example when update sites for different versions of Eclipse platfom get mixed up together).
I suppose a possible mitigation strategy would be uninstalling all the relevant plugins and reinstalling them.
I think the easiest is to just download a 'full' distribution build rather than try to install bits and pieces from update sites. It would also be good to try the full distribution build even if just to verify that it actually works for you (this would help confirm the suspicion that it is some kind of packaging/installation issue that came about because of a combination of cumulative updates over time).
I don't know what "easiest" means, but having to reinstall all of the plugins I use and moving over all of my projects and settings does not seem "easy" to me.
Ok, well, I've confirmed that what I wanted as the easiest solution doesn't work. Uninstalling those three plugins and then installing Spring IDE from the marketplace results in the same error when I try to open a pom file. Any other info I could provide that would be useful?
Dunno whether it matters, but also note that I have the same Eclipse version and very similar plugin set installed on my Linux VM, looking at the same codebase. I don't see this problem.
Uninstalling those three plugins and then installing Spring IDE from the marketplace results in the same error when I try to open a pom file. Any other info I could provide that would be useful?
That makes sense, the problem is likely caused by something in the 'base' install being somehow incompatible or broken in combination with the STS plugins.
If you have steps that we can follow to setup this 'base install' and install the marketplace bundles into it... and then get something broken... that would be something we can investigate and try to fix.
About the Linux note. I also don't know if it matters, but its definitely good to know and keep in mind when trying to reproduce. So you on Windows or Mac then?
Windows 7.
I have no idea how I would set up a "base install" to demonstrate this.
How can I determine what version of the JDT I have? Searching for that in the plugins list doesn't result in an obvious answer.
I have no idea how I would set up a "base install" to demonstrate this.
How did you set it up before?
How can I determine what version of the JDT I have?
Every plugin and feature will have a version, JDT has many plugins though, but just knowing the version of the plugin that contains the class that can't be found would be interesting. That plugin is 'org.eclipse.jdt.core' and the version I have for example is 3.17.0.v20190306-2240.
What will give us all that information and more is if you go to: Help >> About Eclipse (or About Spring Tool Suite. Then click "Installation Details", then select "Configuration" Tab. The text that appears there is dump of everything you have installed their version and a lot more details. So copy and paste that text into this ticket will be useful (and we can find stuff like version of JDT, your OS, etc. etc. in there).
BTW: Be a little careful sharing the dump publically. It also contains a dump of environment variables. Sometime there are 'secret' information in their that you may not want to share. You should edit those out if you are going to share it publically.
Another thing you can try... open "Host OSGI Console" from the console view. Then type command like this "ss jdt.core" this will also give you the version of the jdt.core bundle as well as the bundle's activation state.
osgi> ss jdt.core
"Framework is launched."
id State Bundle
215 ACTIVE org.eclipse.jdt.core.manipulation_1.11.100.v20190301-1946
565 RESOLVED org.jboss.tools.m2e.jdt.core_1.0.1.201209200903
1250 RESOLVED org.eclipse.jdt.core.compiler.batch_3.17.0.v20190306-2240
1298 ACTIVE org.eclipse.jdt.core_3.17.0.xx-201903291337-e1903
Fragments=213, 212
How did you set it up before?
When a new version of Eclipse comes out, I download the installer. I install it. I install the plugins I use from the marketplace. I do have one plugin that I currently have to build locally and put into dropins, the Emacs+ plugin, as the author isn't maintaining it right now.
1298 ACTIVE org.eclipse.jdt.core_3.17.0.xx-201903291337-e1903
I think that's a 'patched' jdt.core bundle, probably from groovy-eclipse. You have groovy support installed? I am guessing this may have something to do with the problem.
Ok. Let me test updating the plugins, then uninstalling groovy, and see what that does.
I installed greclipse myself and opened a pom. Things didn't blow up. I am on Linux though. So maybe its not a good test.
And I confirmed that this does not have an effect on the test case. I installed the latest spring ide plugins, removed groovy, and I still get the pom errors. I'm attaching the config in a sec.
I installed the latest spring ide plugins, removed groovy
Did output of ss jdt.core change after this?
I'm still leaning towards this being connected to groovy somehow. My installation for some reason doesn't get the patched jdt.core. I get this even after installing greclipse:
osgi> ss jdt.core
"Framework is launched."
id State Bundle
117 ACTIVE org.eclipse.ajdt.core_2.2.4.201905102027
305 ACTIVE org.eclipse.jdt.core_3.17.0.v201906032019-e1903
Fragments=303, 304
306 ACTIVE org.eclipse.jdt.core.manipulation_1.11.100.v20190301-1946
If the problem is somehow because of the patched jdt.core, since I am not getting it (don't know why that is)... the problem wouldn't happen.
I really would like to see the 'ss' output after you uninstalled greclipse. Eclipse doesn't allways uninstall every bundle when you uninstall a feature, so its very well possible that the patched jdt is sticking around.
Note that the "ss jdt.core" output I provided earlier was from the config that I reverted to, before the latest spring ide plugin. After updating again to the latest spring ide plugins (showing the symptom), I see that the output of this does not change. I'll now uninstall groovy and see what I get.
Before uninstalling groovy:
215 ACTIVE org.eclipse.jdt.core.manipulation_1.11.100.v20190301-1946
565 RESOLVED org.jboss.tools.m2e.jdt.core_1.0.1.201209200903
1250 RESOLVED org.eclipse.jdt.core.compiler.batch_3.17.0.v20190306-2240
1556 ACTIVE org.eclipse.jdt.core_3.17.0.xx-201903291337-e1903
Fragments=213, 212
After uninstalling groovy:
215 ACTIVE org.eclipse.jdt.core.manipulation_1.11.100.v20190301-1946
565 RESOLVED org.jboss.tools.m2e.jdt.core_1.0.1.201209200903
1250 RESOLVED org.eclipse.jdt.core.compiler.batch_3.17.0.v20190306-2240
1616 ACTIVE org.eclipse.jdt.core_3.17.0.v20190306-2240
Fragments=212, 213
And if it matters, when I've reverted back to the working config and check for updates, this is the list that is offered to me:
Okay so... something interesting... I opened up content.xml for the greclipse update site that I used (this one: https://dist.springsource.org/snapshot/GRECLIPSE/e4.11). And it shows it has a jdt.core bundle:
name='org.eclipse.jdt.core' version='3.17.0.v201906032019-e1903'
So I think that is the patched jdt.core bundle... that I got.
What's interesting is... its not the version you got. Yours is org.eclipse.jdt.core_3.17.0.xx-201903291337-e1903.
Question is... where did you get it from?
Also, if you take a peek inside this bundle's jar. (You can find it somewhere inside your Eclipse install's plugin folder). If you open the jar, can you find the /org/eclipse/jdt/core/IElementChangedListener.class file inside? My current theory is still... something to do with this bundle (old?) and it doesn't have the class STS was looking for causing the problem. If the class isn't there... that would be pretty strong evidence/confirmation of my theory.
More theory / speculation. I think Greclipse may have changed their naming convention for the patched jdt.core version (no longer has the leading 'xx'). Now... as Eclipse/OSGI use more or less 'alphabetic' sorting to determine which version is more recent. The removal of this xx makes the newer patch bundles actually look older. And I think you somehow have gotten stuck with an old version of the jdt.patch (the new one is timestamped '0603' and the old one is '0329' which is almost 3 months older).
I'm not sure where you are getting this old bundle from, but could be it's just cached inside your eclipse installation and keeps popping back up whenever you install greclipse (it gets used instead of the actual bundle from the update site because Eclipse thinks it is newer).
But I already demonstrated that I can install the latest spring ide plugins, then REMOVE the groovy plugins, and the problem still happens.
But I already demonstrated that I can install the latest spring ide plugins, then REMOVE the groovy plugins, and the problem still happens.
Yes, I can't completely explain everything and have chosen to ignore that fact for now. Eclipse does have a knack of holding on to things based on their version numbers. Uninstalling things doesn't allways completely remove everything you installed.
So, if you could open up the xx jar, and please check if the class is there or not it could help to know if I'm on the right track or barking up the wrong tree (as the uninstall greclipse experiment would suggest).
I had already done some searching for that, but I can't seem to find it anywhere, either that class or even that jar.
In the Eclipse installation's "plugins" folder, there's only a single jar: "org.eclipse.equinox.launcher_1.5.300.v20190213-1655.jar".
In my workspace's ".plugins" folder, there is a directory called "org.eclipse.jdt.core" which has ~800 "*.index" files, but no jar files.
Oh... okay, maybe it's a Oomph thing. I have really no idea where Oomph keeps its installed plugins. I never use Oomph myself, I find it complicates things more than it helps me.
Never mind, I don't think even if the bundle is 3 months old... it will reveal much looking inside. THe git history shows its been a long time this class was even touched:
So the reason it's not found probably isn't anything to do with whether its actually inside that bundle or not (almost sure if you'd find that jar and open it... the class is going to be there).
I'm a bit at a loss now to be honest. Maybe grasping at straws a little but my best guess its something to do with the 'xx' bundle being there when its really not supposed to be. If you installed greclipse from https://dist.springsource.org/snapshot/GRECLIPSE/e4.11 like I did, you shouldn't have that bundle. Yet you do, and that is definitely fishy. Not sure where you got the bundle from, could be you had it all along because you installed greclipse 3 or 4 months ago... and it just stuck around in some place where Eclipse/p2 caches osgi bundles.
More straw grasping... Try this:
- uninstall greclipse
- relaunch STS/Eclipse with the -clean option (I'm hoping this will get rid of
xxbundle). - re-install greclipse
- Check the 'ss' output and see which version of jdt.core you got now.
Does it solve the problem?
Well, at least I am right that the 'xx' part of the qualifier was recently changed.
That's the commit were it happened, dated match 29th so about the timestamp of the jdt patched that seems to be sticking around in your Eclipse install. OSGI version order would consider all the 'v' qualifiers to be older than all the 'xx' ones.
If the sequence above with -clean doesn't get rid of the old bundle, I have no more ideas except... please rebuild your STS setup from a 'clean' slate and my guess is the problem will probably go away. I know it's a pain to do, but we have already spent a lot of effort on trying to avoid it as well.
Maybe @eric-milles has some thoughts about this as well since he was the one who got rid of the leading xx qualifier. Still not sure that this is really the problem, but it does seem a little ill-advised to change the qualifier naming in such a way that older things are considered newer than the latest builds.
Hah. I simplified what you asked me to do. Instead of uninstalling and reinstalling greclipse, I simply restarted with "-clean" with everything installed. Fixed it. Problem solved, whatever it was. Yay. I guess we can close this now.
I simply restarted with "-clean" with everything installed
Why didn't we think of trying this from the start :-)
I think yes, we can close this now. Just still curious... what does the ss jdt.core say now. I am betting the xx bundle is gone? I still think this was the culprit.
337 ACTIVE org.eclipse.jdt.core_3.17.0.v201906032019-e1903
Fragments=335, 336
338 RESOLVED org.eclipse.jdt.core.compiler.batch_3.17.0.v20190306-2240
339 ACTIVE org.eclipse.jdt.core.manipulation_1.11.100.v20190301-1946
1164 RESOLVED org.jboss.tools.m2e.jdt.core_1.0.1.201209200903
Sorry for any problems caused. Indeed the "xx-" prefix was removed after much deliberation and testing. Part of the thought process is that developers would be moving through the quarterly releases much more quickly now, so updating an older release is a less likely event.
In addition to the "-clean" option, you can go to Help > About Eclipse Platform > Installation Details > Installation History. From there, you can remove older install states and eclipse will remove older plugins.
No problem, thanks for confirming my theories :-)
Help > About Eclipse Platform > Installation Details > Installation History. From there, you can remove older install states and eclipse will remove older plugins
Except... it doesn't seem to work. p2 is a stubborn beast and looks like it holds on the old plugins somehow. At least I think that's how David got stuck with the old 'xx' bundle.
Anyhow... you are right, the problem will sort itself out on next greclipse release.
Personally, I still think the old xx- convention was a better one, mostly because it's easier to spot that this is a 'patched' bundle. The new 'v' convention looks too similar to how the original Eclipse bundle's qualifier, so it's hard to look at output from commands like 'ss' and notice we are dealing with a patched rather than the original bundle. I think being able to see you are dealing with a patched bundle easily is valuable while trouble-shooting (like we had to do in this ticket). To be honest if it weren't for the 'xx' in the qualifier, I probably wouldn't have realised that David had installed greclipse and so his jdt.core was a patched one.
I also recall from my work on Greclipse in a past life that we needed the 'xx' so that p2 would know to pick the patched bundle over the original one, the xx was crucial to make this happen and the fact that 'xx' is alphabetically after the version convention used by the original bundle I beleave was the reason why it worked (this may have been a 'bug' in p2's handling of feature patches, so maybe that's no longer necessary).