I'm working with Eclipse Version 3.2.1 Build M20060921-0945 on a MS-Windows 2000 SP4 using a JDK 1.5.0-12.
I takes my locale that is es-AR and sets all menu and context in Spanish which I don't like. So I had included in eclipse.ini file one parameter "-nl en".
Since that, "References..." feature in both "Search" and contextual menu stopped working. I removed parameter and ran eclipse with "-clean" but still not working. I don't have any other clue about what is happening. Thank you all in advance.
Beto
Delete all the files in you eclipse data, eg:
<WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core
This should force eclipse to rebuild its index
Had the same trouble with the latest Indigo release of Eclipse, searching for references of a method or class I selected invariably gave 0 results.
Stopping Eclipse, deleting all files in folder <WORKSPACE>/.metadata/.plugins/org.eclipse.jdt.core, and restarting Eclipse afterwards has solved it.
I see a similar problem where search for references (Ctrl + Shift + G) stops working. It works again if I restart Eclipse, but it's still pretty annoying. I'm thinking maybe there's some keyboard shortcut that I hit sometimes by accident that messes up the search.
Go to {workspace}.metadata.plugins\org.eclipse.search and clear the History section of dialog_settings.xml , worked for me.
After trying all of the above and nothing working, I took another look at the file name pattern I was using for file search:
*.java *.properties, *.vm, *.xml, *.xsd
I was missing the comma after .java, so Eclipse wasn't searching my .java files, it was looking for files that matched the pattern ".java *.properties".
Wow did I feel dumb dumb dumb... adding the comma fixed it! Passing along my simplistic solution in case it does anybody else some good...
Strange as it sounds, it does seem that the keyboard mapping affects this. I had mapped -H to Search in Files, and the Java search started bringing up everything, rather then actual references to the method I was searching for. ~Nothing~ fix this, including the solution above. But remapping the key to Open Search Dialog DID fix it.
I've just come to experience this behaviour with Eclipse Mars 1 Release 4.5.1.
In an specific class only. Clean and build entire workspace does not work but I've updated Maven Project containing that class [Right-click on project -> Maven -> Update Project ...] and it works now.
Hope it helps someone.
I've just come to experience this behavior with Eclipse Mars 1 Release 4.5.1.
I tried everything mentioned above but it did not help.
So I created new workspace, and imported the project and search started working again.
I was facing a similar issue in Eclipse 2019-09 R (4.13.0) on Linux Mint
One thing that worked for me (besides closing and opening Eclipse again) was to click on the search icon and then in the Show Previous Search icon on the tab and then Open in New :
Trash your install.
Then reinstall it.
Related
I have a non-exist project which I am unable to remove from Eclipse. I am just checking if there is any other way to remove it.
Process of deleting project I am using:
Selecting project -> right click -> select delete -> follow the wizards
Result: a fatal error occured while performing the refactoring
found-problem client-target does not exist anymore
VinyJones answer did not work for me, since there was no corresponding metadata for the non-existant project. The solution for me was to drag the non-existing project to an other working set. After dragging it disappeared.
You may try this :
Close your workspace :
Delete the dir client-target from <workspaceDir>\.metadata\.plugins\org.eclipse.core.resources\.projects
Open your workspace
And should be good
none of the above worked for me but this solution worked (was really a ghost project)
Shut down Eclipse
Open <workspace>/.metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml
Find the faulty tag and remove it
Start Eclipse
For me neither solution worked.
I'd to go to "Select working set" then select "Windows working sets".
The project then appeared without working set and I was finally able to delete them.
Running Eclipse with the -clean command line parameter works also.
I found all the answers here to be a little too elaborate and/or risky. So I closed eclipse (actually I had to force delete its sad, broken husk from Task Manager) then started it again.
Then I was able to right-click delete the packages from the package explorer.
Sounds like the solutions here are red/black on the roulette wheel. Maybe one of them will work for somebody? I miss .NET!
What should I do, if the "Open Call Hierarchy" is broken (empty for every method in a project)? It only shows the name of the method I wanted to see the call hierarchy for. This happens for all methods I try, even though they are all called by other methods.
It is very useful for code navigation. I do not know how to work without it!
I've tried:
Opening eclipse.exe -clean -refresh
Restarting Eclipse
Closing and reopening the project
Updating the project
Renaming the .metadata file
I've checked that it searches the whole workspace, and there are no filters on.
The following may help:
Calling eclipse with eclipse.exe -clean -refresh forces Eclipse to rebuild the index. After that the feature worked again.
Closing and re-opening the project.
I also tried the suggestions above, as well as the hint given here: http://mschrag.blogspot.co.at/2009/01/open-type-cant-find-your-class.html
Nothing worked until today when I found out that I am a donkey...
I once configured a filter in the "Call Hierarchy" view and so no entries were shown because filtered out. Once I removed / disabled the filter everything worked fine again.
When you go to the eclipse bug report for this issue, somebody says, you should install over the Market place the Java 12 support.
When I installed it, it was working properly again
Also, you can try to delete the workspace and get it recreated. Make sure all your projects are backed up.
For Kepler and PDT (PHP IDE) it is broken in at least PDT 3.2.0 and 3.3.0 (tried them both). The fix is in 3.3.1 and updating to that was all I had to do get the call hierarchy working again.
(apologies, I'm not yet allowed to add comments, however this should prove handy to many)
In my case it seemed my workspace was contaminated.
Opening/closing projects and starting with clean did not fix. I had to start off a new workspace.
Fedora 20, Eclipse Kepler.
I have the same behavior with eclipse Kepler (4.3.2).
I found out, that there is a bug with methods with signature of:
void get(Object o)
Object get(Object o)
In the eclipse Error Log view I find the following exception:
java.lang.NullPointerException
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.directoryTable(ClasspathSourceDirectory.java:52)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:109)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findClass(JavaSearchNameEnvironment.java:146)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findType(JavaSearchNameEnvironment.java:185)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2799)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2556)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getType(MatchLocator.java:899)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding0(MatchLocator.java:955)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding(MatchLocator.java:907)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchMethod(MethodLocator.java:327)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:664)
at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:209)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1699)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1143)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1184)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1301)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584)
at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
In the end, it looks like a bug in this version:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401272
I assume, that upgrading at least to version 4.4 (Luna) will solve this problem.
In my case I was trying to get the call hierarchy of a method in the derived class of an abstract class. The requested method was declared abstract in the base class.
When I opened the call hierarchy directly on the abstract method instead of the implemented one, everything worked well. (Eclipse Neon).
My problem was that Open Call Hierarchy was searching only the project not the entire Workspace.
So I had to click on the small down arrow (in the Call Hierarchy view window on the right; it is the "View Menu" arrow -- a triangle pointing down) in Call Hierarchy view, set the Search Scope > Workspace.
Tried everything in all the answers here, but none of them worked for me. Later I figured out that this was a bug in Eclipse 2019-03 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=545293). Try to upgrade your eclipse or install a newer version.
For me installing a newer version(latest version Eclipse 2019-09) solved the problem.
I tried many answers all were great, it helped many except few and I was in few.
My eclipse version is 2019-03(4.11.0). This is which has a bug. Which can be fixed by add-ons.
Go to the Eclipse Marketplace and search for plugin java 12 Support for Eclipse 2019-03(4.11)… and install it. On completion of installation restart the eclipse. Hopefully this will fix the problem. Have a nice day.
If the call Hierarchy is not opening, it might be because of the project is not imported as a java project, rather it would be displayed in the file stucture. You may want to enable the project facet through:
right click on the project -> project facet.
If you dont see anything listed, you need
configure the project facet -> Apply -> ok.
I was working fine with an Eclipse Juno on a Maven java project - all hunky-dory for couple of weeks.
Yesterday, just before leaving for home, I ran 'mvn clean' and 'mvn install' on the command line for the project (all good). I did not try opening Eclipse after running 'mvn' on said project from the command line.
This morning opening Eclipse Juno does not work - it stalls on loading 'org.eclipse.m2e,core'.
Can anyone give guidance on what could be going on?
I would rather not delete Eclipse and re-install - too painful!!!
I am using Macbook with Oracle JVM 7.
Delete the folder ".org.eclipse.e4.workbench" in ".metadata/.plugins" within the problem workspace and start eclipse with the -clean flag.
If this doesn't help also delete all files ".markers.snap".
I just have to delete the file workbench.xmi from directory
[*workspaceXYZ*]/.metadata/.plugins/org.eclipse.e4.workbench
Then the workspace starts again. But this is really a pain...
Just adding extra case for same old problem (as i encountered the problem now and was able to solve it):
For me too i had exactly same problem, other work space were working except for this. I did not wanted to delete this problematic workspace. So what I did was, first I loaded some other work space for which eclipse starts. Then I clicked "switch work space" and tried to open the same work space which had was problem. Then it worked
You can try steps in this answer. This didn't work for me so then I tried deleting the whole workspace/.meta folder. This did work for me but I now have to reimport my projects - so not perfect.
Seems your eclipse in doing something with M2E the maven plugin, maybe try to remove the plugin from eclipse installation first. Then try to restart eclipse.
If everything is ok, then install the plugin agian.
To me was necessary to do both solutions above:
Delete the folder ".org.eclipse.e4.workbench" in ".metadata/.plugins"
I loaded some other work space for which eclipse starts. Then I clicked "switch work space" and tried to open the same work space which had was problem.
Then it worked!!! :D
I use Eclipse PDT with Aptana. When I started working, I could reliably use ctrl-click (or F3) on method names or functions to directly jump to the declaration.
Today, suddenly this does not work any more for all methods, it just works for some. I could not find out for which it works, yet.
I have already refreshed the project (F5 in PHP explorer window) and started eclipse with the "-clean" option, but neither helped. Hyperlinking is actived in the settings.
EDIT: I am using Helios Service Release 1, Build id: 20100917-0705
What can I try to make it work again?
Did you update Eclipse?
"Remove files under workspace/.metadata/.plugins/org.eclipse.dltk.core.index.sql.h2
Kepler repository has newer version of h2 database. It is incompatible to older one.
See eclipse/plugins folder, there might be org.h2_1.1.117.v201105142352.jar and org.h2_1.3.168.v201212121212.jar. (don't touch them)"
Okay, it looks like it was a user fault. My fault ... I had too many projects opened at the same time. Now, when I have only one project open, the hyperlinking works quite well again. I will watch further, but I am quite hopeful that I can now enjoy the full functionality of eclipse again.
What did the job for me was this:
http://fsse8info.wordpress.com/2013/10/14/howto-get-eclipse-pdt-open-declaration-f3-working-again-with-php-files/
Closing unrelated projects worked for me too, I was actually facing 2 issues.
Both intelligence ( ctrl+space) and open declaration were not working. After clicking (right click->close unrelated project), Problem solved for me as well.
If all above solutions don't work and still facing issues with some directories. Then you need to make sure .buildpath doesn't miss any directory and have all entries like:
buildpathentry kind="src" path="dir/dir1"
buildpathentry kind="src" path="dir/dir2"
Your file has errors from classes missing a library reference. Right click project, Java build path, add library to fix reference issues, then the ctrl+click will work again
When I select a folder in the Eclipse Project Explorer, the 'explosion' often will cause a file to 'moved' out of its current folder - sometimes even to another project - causing errors in the re-compilation (thankfully).
Does anyone have a solution to this 'tenderness'? (If relevant, I am using Ganymede under Eclipse 3.4.2 with the Android Plugin.)
My theory is that the OP is accidentally doing a drag-and-drop and moving files. I couldn't see a simple way to turn off drag-and-drop in the preferences editor.
I worked On Eclipse Ganymede in Linux
I think there is problem with your Setting of editor
I work with Eclipse a lot, I've used Ganymede for over a year under Linux and sometimes Windows, and neither I nor any of my colleagues have ever seen such a problem.
My guess is that there are problems between your mouse and display drivers, i.e. you are inadvertently clicking on other things when you are meaning only to explode. Can you try opening folded branches by selecting the item and hitting the + key rather than clicking in the GUI?