title: Eclipse auto refresh (after custom builder) does not discover new files
body: <p>This is not another of many "how do I have Eclipse auto refresh" questions. My problem is that it <em>does</em> but not entirely.</p>
  
  <p>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). </p>
  
  <p>What I've done so far is:</p>
  
  <ol>
  <li><p>Add a dummy custom (ant) builder AFTER the standard one and set it to "refresh selected resources" - the source folder of those generated projects.</p></li>
  <li><p><strong>Also</strong> 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.</p></li>
  <li><p>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.</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>... and that outcome is that <strong>Eclipse does indeed notice the files that have been modified</strong>. 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). </p>
  
  <p>However, I never got to have it automatically discover that <strong>a brand new file that did not exist before was created</strong>. 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).</p>
  
  <p>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...".</p>
  
  <p>Is it possible that this is still impossible in Eclipse? Does anyone know of a plugin (if not a direct solution) that can help?</p>
  
  <p>As I noted in comments, discovering new folders (Java packages) also does not seem to be a problem. Just new files in existing folders.</p>
  
  <p>Thanks!</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>With <strong>all the refresh things I did in place</strong> I noticed something I did not before.</p>
  
  <ol>
  <li>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.</li>
  <li>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).</li>
  <li>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.</li>
  <li>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.</li>
  </ol>
  
  <p>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?</p>