This is not another of many "how do I have Eclipse auto refresh" questions. My problem is that it does but not entirely.
In a workspace with multiple projects the compilation of one causes source code to be generated in other(s) (that exist purely for this purpose - no manually written source code there). Source code is generated during the main compilation itself (i.e. not a custom builder, but a plugin for the Scala compiler, but that should be irrelevant).
What I've done so far is:
Add a dummy custom (ant) builder AFTER the standard one and set it to "refresh selected resources" - the source folder of those generated projects.
Also add a dummy custom (ant) builder BEFORE the standard (Java) builder of generated projects that refresh the same thing. Actually I tried various versions - just the source folder, the entire project, or the entire workspace with the same outcome. Note that those generated projects are set to depend on the project whose compilation generates their source code.
In Window -> Preferences -> General -> Workspace enabled "Refresh using native hooks or polling" in addition to "Refresh on access". I also tried disabling "Refresh on access" (leaving only the other one). Same outcome.
Tried with Eclipse Indigo (3.7 SR2 20120216-1857) and Juno (4.2.2 M20130204-1200), both 64-bit Windows versions. Additional plugins are installed, most notably Scala IDE (multiple different versions both for Scala 2.9 and 2.10 ending with Scala IDE 3.0.0). Same outcome.
... and that outcome is that Eclipse does indeed notice the files that have been modified. In whatever was the best combination of settings of the above (forgot) I was even able to get it to notice that some files that used to be generated no longer are and have them disappear (although I still had to collapse the tree and re-expand it, but no F5 was needed).
However, I never got to have it automatically discover that a brand new file that did not exist before was created. In my case that also yields compilation errors (since the modified files that it does discover have changed refer to the code in new files it does not notice).
Simple F5 solves the problem, but it is killing me, as I am trying to roll this environment to other developers and I'd hate having to tell them "You know, you have to (keep) push(ing) F5 every time you...".
Is it possible that this is still impossible in Eclipse? Does anyone know of a plugin (if not a direct solution) that can help?
As I noted in comments, discovering new folders (Java packages) also does not seem to be a problem. Just new files in existing folders.
Thanks!
UPDATE
With all the refresh things I did in place I noticed something I did not before.
I make the change in the project that causes code generation (was trying to test if it is the re-appearance of previously disappearing file is an issue or otherwise). This time I was just renaming one method which caused a name of the generated source file (Java class) to be changed as well.
As "Build automatically" is enabled, Eclipse begins the build. Very quickly it discovers an error and complains about it - one generated class that was modified now refers to a class Eclipse does not see yet (because refresh is incomplete - saw the modified file, but still believed that the file that no longer exists is there and did not see the new file).
Build actually continues. Progress goes up and down, appears and disappears a number of times, building other dependent projects. All the time the error is listed and marked in the Package Explorer on the modified class.
After the build seemingly completes (with that error in it, some minutes later), the refresh completes (!!!). Package Explorer is updated, the old file disappears, the new file appears, the error disappears, etc. I initially attributed this to me switching windows and triggering the refresh that way but I made sure I touched nothing the last time - just made the change and pushed Ctrl+S to save it.
This may mean that the 'condition' is not so bad (one just has to be very patient and have nerves of steel). Investigating further. Thanks to all who are or may be doing the same! The question is still why are there two refreshes with the first one being incomplete?
Related
It doesn't make sense to have user dictionaries for multi-developer Eclipse projects, so I'm looking for a solution that would allow me to share a spell-check dictionary with all users.
As you can imagine the checkout and eclipse locations can be different for each user.
Also the dictionary should stay inside project directory because I want to add it to the version control system used by the project.
This question is targeted to the latest released version of Eclipse 3.7
To use project-specific dictionaries in all your projects, you could create a file .dictionary at the root of your project, and set the value of the "User defined dictionary" at (General->Editors->Text Editors->Spelling) to ${project_loc}/.dictionary. I don't know how to have BOTH a global dictionary and a project-specific dictionary, as the relevant preference page allows only one "User defined dictionary".
Note: that there can be some very confusing behavior when you don't have .dictionary files defined in a project. The behavior depends on some hidden cache behavior of the spell-checking implementation and your previous actions, and might be considered an Eclipse bug.
If you have just opened Eclipse, go to a project without a .dictionary, edit some file, and add a spelling to the dictionary, Eclipse will create the .dictionary file. That is strange because it won't even do that from the main wizard page. You have to create the file manually first before you can specify it.
If you were first working in project that does have a .dictionary, then switch to a different project without one, edit a file, and add a spelling, Eclipse will add it to the .dictionary in the original project!
Deleting entires in the dictionary or deleting the dictionary file will not cause the added words to be relabeled as misspelled, regardless of refreshing the project or file. Closing and reaping Eclipse does, however, restore the "misspelled" status of words.
FYI, I am using Eclipse Indigo Service Release 1; Build id: 20110916-0149 on Mac OS X lion.
I develop Java code with Eclipse and regularly get this message:
resource is out of sync with the filesystem.
Right-click > Refresh will always clear this.
But why can't Eclipse refresh automatically when it finds this condition? Are there cases where you want the resource to be out of sync?.
If there are such conditions and they don't apply to my work, is there a way of getting Eclipse to refresh automatically when it encounters this state?. (I appreciate that it should refresh as little as it needs to in normal development to increase performance for human developers.)
UPDATE (2012-06-25):
My latest update (Version: Indigo Release Build id: 20110615-0604)
no longer shows
Preferences - General - Workspace - Refresh Automatically
There is an option "Refresh on access" - should I use this?
You can enable this in Window - Preferences - General - Workspace - Refresh Automatically (called Refresh using native hooks or polling in newer builds)
The only reason I can think why this isn't enabled by default is performance related.
For example, refreshing source folders automatically might trigger a build of the workspace. Perhaps some people want more control over this.
There is also an article on the Eclipse site regarding auto refresh.
Basically, there is no external trigger that notifies Eclipse of files changed outside the workspace. Rather a background thread is used by Eclipse to monitor file changes that can possibly lead to performance issues with large workspaces.
Just right click on the file or on the project and click Refresh. The error will vanish. I also faced the same issue and it worked for me.
Window -> Preferences -> General -> Workspace
For the new Indigo version, the Preferences change to "Refresh on access", and with a detail explanation : Automatically refresh external workspace changes on access via the workspace.
As “resource is out of sync with the filesystem” this problem happens when I use external workspace, so after I select this option, problem solved.
This happens to me all the time.
Go to the error log, find the exception, and open a few levels until you can see something more like a root cause. Does it says "Resource is out of sync with the file system" ?
When renaming packages, of course, Eclipse has to move files around in the file system. Apparently what happens is that it later discovers that something it thinks it needs to clean up has been renamed, can't find it, throws an exception.
There are a couple of things you might try. First, go to Window: Preferences, Workspace, and enable "Refresh Automatically". In theory this should fix the problem, but for me, it didn't.
Second, if you are doing a large refactoring with subpackages, do the subpackages one at a time, from the bottom up, and explicitly refresh with the file system after each subpackage is renamed.
Third, just ignore the error: when the error dialog comes up, click Abort to preserve the partial change, instead of rolling it back. Try it again, and again, and you may find you can get through the entire operation using multiple retries.
If this occurs trying to delete a folder (on *nix) and Refresh does not help, open a terminal and look for a symlink below the folder you are trying to delete and remove this manually. This solved my issues.
When you open an Eclipse workspace from within a clearcase view and try to rename the project, you will often get the pop-up warning ... “Resource ‘project’ is out of sync with the file system”. If refreshing the project does not fix the problem, then do the following workaround: a. Open workspace WITHOUT being in a view b. Select the project in Project Explorer c. ClearCase -> Associate Project (project should now look like project [] ) d. Right click project -> Refresh (vob sub-folders should now be empty) e. Right click project -> Rename ... f. Enter New name
Now you can close the workspace, reopen it in a view and refresh the project. You may also dissociate the project if you prefer the project not to be associated with the vob.
A little hint. The message often appears during rename operation. The quick workaround for me is pressing Ctrl-Y (redo shortcut) after message confirmation. It works only if the renaming affects a single file.
If you are a regular Eclipse user than you might have got this error many times. The error simply says, “you’ve made changes in files in your workspace from outside eclipse”. The simplest solution would be to select the project and press F5 (Right click -> Refresh).
if you need more explanation you can read from this web site
I was not able to resolve this error by either refresh or by turning on "native polling" workspace feature. Turned out my project was also opened in two instances of eclipse. Once I closed the other instance, the error went away. So make sure your project is only opened at one place if you are seeing this error.
I've got an Eclipse (Galileo) project (called ProguardBuilder) that runs Proguard over a set of class files in other projects and produces a jar file.
I'd like to have the ProguardBuilder project get rebuilt any time any class file in the other projects changes. AutoBuild doesn't do that; presumably it's smart enough to recognize and ignore any changes that don't affect anything externally visible.
My problem is that I don't care whether or not the change is visible, since I need to completely rebuild ProguardBuilder any time the class files it depends on change at all.
How do I tell Eclipse to do this sort of rebuild?
You might have to use an external builder. Check the documentation, because I've never done this. But the place to start is the "Builders" section of the project properties dialogue.
If you press Shift+Ctrl+T or choose "Navigate > Open Type..." you get the "Open Type" dialog for quickly navigating to a known class. When you start typing a name only the classes for which the name matches stay visible. That way you can find a class of which you know the name very quick without having to browse through the package explorer tree.
This has been working great for me up until this morning. All of a sudden for a couple of my projects I am only seeing some of the types that exist. Of course I tried the obvious steps of refreshing the projects, cleaning the projects, re-building the projects, rebuilding the projects externally, but all to no avail. It is a bit odd since the types are known in other places. If I add an import statement Eclipse does not complain that it doesn't know the type and I can Ctrl-Click through the types to get to their file. However, the type navigation knows nothing about them.
In the past when InteliJ used to do this to me I would go find its cache files and delete them forcing it to rebuild. Does Eclipse have something similar I might do (I'm an Eclipse newbie)? I am using Eclipse 3.4.2 and I have it configured to not delete files on a clean (because our actual build process puts files into the output directories that I don't want Eclipse mucking with).
Have you tried closing and reopening the project? Only types from open projects are held in memory, and the refresh occurs when you Shift+Ctrl+T for the first time on a newly opened project.
Edit to add: Ctrl+Shift+R also displays the types (along with everything else) but it also supports the Camel-case thing to find the Java types quickly.
Close eclipse and delete any .index files and the savedIndexNames.txt file in workspace/.metadata/.plugins/org.eclipse.jdt.core once eclipse is restarted it will rebuildl the entire index for Ctrl+T
try starting eclipse with the -clean flag, you can add this to your eclipse.ini which can be found in the same directory as you eclispe.exe, or if you start eclipse using a bat or shell script, add it as a startup argument, e.g. eclipse -clean.
The clean will tidy your workspace, and should force eclipse JDT to recalulate types. Ive had issue with .snap files (with seem to be created on dirty shutdowns) that seem to corrupt my workspace until I clean them up, not long ago eclipse lost the Object class!! made for some interesting errors!
I get problems like this often. I tried your solution, noticed it seemed to rebuild its search index, but I still couldn't find any of my classes. Then I took a look at the little green arrow on top right corner of that dialog, and noticed I had a working set selected which belonged to another project. I find it a little dumb that Eclipse doesn't warn you about this or anything, since this can be a very annoying little detail that one tends to forget (me at least ;-)).
Anyways, clicked on "Deselect Working Set" and bam I can find my classes again. Thought I'd add this here since others may make the same mistake.
This worked for me -
Select your project in Package Explorer
Press F5 or Right click and select Refresh
I used the "-clean" as first line in the eclipse.ini (version Juno) and worked like a charm.
I'v tried all the answers and I still had the issue. I then tried this:
I deleted the project (it's a maven project) and re-imported it. This time I made sure i check the "Add Project(s) to working set" checkbox. After that Eclipse was able to find the classes in that project.
The problem must have started because I didn't check this checkbox when i first imported this project.
By the way, I'm using Neon
(Warning: Shameless marketing ahead)
If you like this feature, you would love nWire. nWire allows, among other things, to quickly search not only for types, but for any possible Java element like method or field. It also uses a navigator view which is non-modal. After searching you can see the class associations in a very quick and easy way. Check out the video on our site.
I've got a small project which, when run in the Eclipse debugger, always seems to stop in FileInputStream.class line 106, where files are opened. There are no breakpoints set, but Eclipse behaves exactly as if I have a breakpoint here. If I clear all breakpoints, it still happens.
I have a second much-larger project in the same Eclipse workspace which does not suffer from this problem.
I just moved the smaller project off of my old Linux machine, where I developed it in Europa Eclipse and had this problem, onto my new Windows machine, where I continue to see the problem in Ganymede Eclipse. The problem persists across operating systems and across Eclipse versions, yet apparently not across projects. I don't get it! I grepped through every file in this project's directory and couldn't find anything that might be a file somehow directing Eclipse to stop in FileInputStream.
Further info: the apparent breakpoint is actually not for line 106 of FileInputStream; it appears to be an Exception breakpoint for FileNotFoundException, being thrown from native code called from that line in FileInputStream. But again, I don't appear to have any breakpoints set at all. Are Exception breakpoints defined somewhere else?
Did you try to un-select
Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions
? (as mentioned in this thread, for instance)
Why does Eclipse work that way?
It goes back to 2002, when the breakpoint object hierarchy has been stripped down.
In order to set a breakpoint, with the old API, a client required Java Model Objects - such as IType, IField, etc.
With the new API, all that is required by the debug model is type names, field names, etc.
This allows clients to set breakpoints when Java Model Objects are not available.
Clients now specify the resource to associate a breakpoint with (before we constrained it to the associated Java Model resources).
Breakpoints can now also be "hidden". That is, they need not be registered with the breakpoint manager.
Breakpoints can also be selectively persisted (markers only allowed all/none of a marker type to be persisted).
This makes the debug model more flexible, and gives clients more building blocks.
This has also simplified some part of our Java debug implementation - for example, the feature "suspend on any uncaught exception", simply sets a breakpoint for the type named "java.lang.Throwable", rather than a specific IType in a specific project.
The breakpoint is not registered with the breakpoint manager (i.e. hidden) - it is only known and used by one client.
Another example is the "run to line breakpoint". The IJavaRunToLineBreakpoint has been removed, as its special functionality is no longer required. Now, the Java debug ui simply creates a "line breakpoint" that is hidden, non persisted, and has a hit count of 1. This is an example of providing building blocks to clients.
I had a similar problem but the accepted solution did not work for me. I am doing Eclipse Android development and had set some breakpoints and later unset them. Even though I disabled them Eclipse kept stopping execution at these phantom breakpoints. The solution for me was to open the Breakpoints window:
Window > Show View > Other...
Debug > Breakpoints
Then right click any breakpoint and select "Remove All"
Unfortunately you have to reset all your valid breakpoints, but this worked for me and has prevented much angst and frustration going forward.
Some pictures to guide others:
For those who don't find other solutions useful, I found my personal solution to my problem. I work with a .jar library which is generated by building another project into the workspace. If I set a breakpoint in a .java into the library project, then the breakpoint will be triggered when debugging the final project. However when debugger pauses the execution the .class file is shown which has its own breakpoints and therefore the breakpoint set into the .java file is not shown here!
Solution:
In order to remove the breakpoint you have to remove the breakpoint into the .java file, in the library project.
I ran into an issue where a source file had persistent markers for breakpoints that didn't exist. I tried cleaning the project, doing a full build, restarting Eclipse - nothing worked.
I went digging through the Eclipse metadata, and found the projects .markers file. Deleting that file finally fixed the issue.
For anyone else having this issue, open your workspace directory, then navigate to .metadata/.plugins/org.eclipse.core.resources/.projects/your project, then rename/remove file .markers.
For example, if your workspace folder is ~/workspace, and your project is named Foo, you could do:
$ mv ~/workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/Foo/.markers ~/safe.Foo.markers
For those who didn't find a solution from the previous answers, they can try what solved my problem. It is I think similar to HAL9000 problem/solution
If you have two classes with the same name (in two different projects) the breakpoints on the one, apply on the other one as well. Both of them show in the "Breakpoints" window.
Solution: If you remove the breakpoint from the class - with the same name - that you are not using it removes the breakpoint from the class you are debugging.