Community
Participate
Working Groups
Build ID: I20070323-1616 Steps To Reproduce: Unfortunately I can't find a way to reliably reproduce the problem -- it seems to happen randomly. More information: Every now and then, Eclipse will tell me it cannot find my custom extension point names that are being imported using <extension-point ../> I'm not exactly sure how to make the errors go away but usually a combination of restarting the workbench and copying/pasting XML manually from the plugin.xml will do the trick. The errors that show up actually show in the extensions of the custom extension point, i.e.. "Unknown extension point x.x.x"
Thanks. We would like to iron out all validation issues before 3.3 ships. Hopefully you can find a reproducible scenario in the near future.
I have a project that is targeting Eclipse 3.2. I set up a target platform based on Eclipse 3.2 in a separate directory. When I try to open my 3.2 workspace for my project using Eclipse 3.3, and I try to rebuild my plugins, any plugins that have an extension point show up as having errors. All of the errors are of the following flavor: Unknown extension point: 'org.eclipse.ui.preferencePages' When I reopen the workspace with Eclipse 3.2, everything works fine. This is occurring on a windows machine, with a full Eclipse 3.3 sdk installation and no other plugins installed. The other weird thing is that I can actually launch my application with all of those errors from Eclipse 3.3 and it runs just fine.
I'm also seeing such validation problems occasionally with latest builds. I guess I first saw it a few weeks ago, but then I was not sure whether it was due to a recent workspace crash. Now, I got it after accepting an unrelated update in org.eclipse.jdt.ui/plugin.xml from CVS. My workspace is now in a state where the PDE manifest compiler flags 2 invalid errors in that file. The errors don't go away on Project > Clean. Also restarting Eclipse did not help. The only way I found to make the errors go away is to close and reopen the enclosing project. Unknown extension point: 'org.eclipse.debug.ui.consoleLineTrackers' org.eclipse.jdt.ui plugin.xml line 1990 Unknown extension point: 'org.eclipse.team.ui.teamContentProviders' org.eclipse.jdt.ui plugin.xml line 5226
> Now, I got it after accepting an unrelated update in > org.eclipse.jdt.ui/plugin.xml from CVS. My workspace is now in a state where > the PDE manifest compiler flags 2 invalid errors in that file. Markus, any chance you can help me with the steps to try to recreate the update? I can check out jdt.ui, but would just need to know (roughly) what versions you saw the problem on. If we can find a reproducible scenario, I would be more than ecstatic and would do my best to fix the problem.
For right now, I will keep this bug opened but it could be a possible dup of 205457. Note in comment #3, it talks about recent builds while 205457 talks about 3.2.2.
(In reply to comment #4) I had /org.eclipse.jdt.ui/plugin.xml 1.762 in my workspace (no compile errors) and then accepted the incoming change to 1.764 (which lead to the compile errors in comment 3). I have most required projects from CVS (including the declarators of the unresolved extension points). Unfortunately, I cannot reproduce these problems in a fresh workspace. What I found however, is that the whole extension points model is screwed up. E.g. links to extension points on the source page don't work (Ctrl+Hover does not show a link, context menu on references don't show Open Schema, Show description, etc.). Also, a Plug-in Search for All Occurrences of Extension point "org.eclipse.debug.ui.consoleLineTrackers" in scope All does not find any matches, not even the declaration! Can you tell me where the PDE manifest compiler persists its build state / extensions model? I guess something's wrong there, and cleaning bogus state would help. If it helps, the solution to this problem would be to clean that state also on Project > Clean.
Recently we have changed the way extenions/extension points are stored. The cache for a workspace is in the <workpace>/.metadata/.plugins/org.eclipse.pde.core/.extensions folder. This is a registry which contains information for all the plug-ins in the target platform and workspace. We don't want to clear this on a project clean because the cache is responsible for all plug-ins. If we cleared this, we would have to reparse all the plug-ins from the target platform all over again, becoming very inefficient.
After clearing the .extensions folder and then rebuilding the affected plugin.xml files, everything works fine now for me. FWIW, I still have the broken files in case you're interested in them.
Thanks for keeping a copy of the broken files. What would be super helpful is if I could find steps on how to break it :) I am not sure how we are getting into an invalid state. If you run across it again, please try to remember what steps you took that might have made it go crazy.
(In reply to comment #7) > We don't want to clear this on a project clean because the cache is responsible > for all plug-ins. If we cleared this, we would have to reparse all the > plug-ins from the target platform all over again, becoming very inefficient. That's half-way acceptable when I clean a single plug-in, but when I clean all projects, then this cache must be dumped.
I'm still not able to reproduce, although the problem still shows up occasionally, even in the workspace that was "fixed" by removing the ext.pt. cache. However, I found a possible reason: I often update changes from CVS in batches, which leads to situations where the update jobs are blocked by the autobuild job. In this case, I sometimes cancel the autobuild job manually in the Progress view (to work around bug 89301). If the PDE compiler does something wrong when canceling a build job, then this would explain why I am seeing this but not others in our lab (because they're not cancelling autobuild jobs).
Just got this today. PDE insists on saying that the extension point "org.eclipse.core.runtime.adapters" is not present. Touching or replacing the plugin.xml did not help. I had to delete the .extensions directory as outlined in comment 7. After that I had to touch each plugin.xml manually (or clean each affected project). Quite a pain - raising severity.
Dani, which build were you using?
>Dani, which build were you using? I20071204-1547 I was updating from CVS and also imported the required binary plug-ins from I20071204-1547.
> I was updating from CVS and also imported the required binary plug-ins from > I20071204-1547. I have the same problem with I20071212-0010 now, and I also synchronized and imported binary plug-ins in parallel. Maybe it's a concurrency issue in the plug-in registry. If you can't fix this soon, then please at least reset the registry on Clean all.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
