Community
Participate
Working Groups
Technical details: Eclipse version: eclipse-SDK-2.1-win32.zip Also tried on: eclipse-SDK-I20030528-win32.zip OS: Windows XP SPK 1 System: Pentium-III 550 MHz w/ 384 megs of RAM First of all, let me say that this problem is going to be difficult to reproduce. That said, I think it bears at least minimal investigation. We have two "simple" projects (checked out from CVS) which we have "wrapped" within a third Java project. The Java project has no additional source - it is merely a wrapper. The Java project contains, therefore, on its Java Build Path (in the project settings) two folders that have been linked to the two simple projects' source folders, thus logically unifying them as one Java project. In addition, we have our projects split into multiple directories, e.g. one for some business logic, one for utilities, and so forth. Each of these multiple directories contains a "src" subdirectory, in which is found the usual package structures. So, the Java project's complete build path is actually a bunch of these "src" folders (which are located inside of the linked folders representing the two "simple" projects), along with the usual JAR files and so on. Everything is fine as long as nobody adds a new directory outside the current build path and then tries to add it. We add the new directory's "src" subfolder to the build path, doing nothing different than with any of the other "src" directories already on the build path. Referencing a class that is inside of the new directory results in Eclipse telling us that we need to import it - that's all well and good, we hit the quick-fix button and it inserts the necessary import. At this point the behavior becomes very odd. The import statement has an error indicator next to it saying that the *package* cannot be found. Mind you, if you go to the import statement and hit the F3 key, you will be successfully whisked away to the class whose package supposedly cannot be found (and that class contains no errors). In addition, if you delete the import statement and paste it back in yourself (literally, CTRL-X and CTRL-V without any other keys pressed), you will be able to build the project without a problem, and in fact any other class that ALSO referenced the offending package will have its problems listed as fixed during the build process. Now, it gets a little weirder. Doing a *RE*build of the project restores the error indicators to the import statements and to all of the actual uses of the offending package/class. Again, hitting CTRL-C, CTRL-V and doing a "Build Project" will make the problem go away. This seemed like it might be a build-order problem, or something along those lines. One person here tells me she was able to get the problem to go away by moving the newly added folder higher up in the build path order. I cannot verify this. I tried closing and opening the project, closing the project and then closing eclipse and opening the project up once eclipse came back up, and doing several "Refresh"es on the source trees in the Resource view. Nothing worked. What did finally work was deleting the Java wrapper project and then recreating it EXACTLY as it was before, the one difference being that it included that new "src" folder right from the get-go instead of being manually added later. I was able to reproduce this error by creating another project that did not include the folder from the start, and then adding it manually. I then tried moving the offending folder higher in the build order and it did not fix the problem for me.
New SRC folder was added to the end of the build order, which resulted in errors being generated for code that was trying to use it. Moving the SRC folder higher in the build order resolved the problem. Suggestion: Couldn't this be detected in Quick Fix? If the class cannot be found at compile time but the class exists in the workspace and in the build path, perhaps suggest to the user that it be moved higher in the build order?
User error.
