Community
Participate
Working Groups
This may be similar to bug 130309. We have a project with a signifanct number of classes (over 1000). We have a package structure similar to what follows: com.ezrez com.ezrez.a.some.packages com.ezrez.common com.ezrez.d.other.packages We have a problem that when we clean the project and it rebuilds, classes in packages *before* com.ezrez.common (alphabetically) are OK but classes in packages *after* com.ezrez.common get compiler errors: "The import com.ezrez.common cannot be resolved". However the class in com.ezrez.common *does* exists and if you add a space to the error class it recompiles and is happy. If you incrementally go and add spaces to the (hundreds of) files with these errors, you will see the number of reported errors go down until Eclipse somehow decides that it should do a clean and rebuild, at which point we are back wehere we started. I experimented and created a class that referenced a class in common. I duplicated this class and put it in various packages. I put it in com.ezrez, com.ezrez.a, and com.ezrez.z. The classes in com.ezrez and com.ezrez.a compiled fine; the class in com.ezrez.z failed with the error I described above. Again, if I added space to this class after the clean and saved it it compiled ok and the error went away. I can't, unfortunately, send you the source to our project and it has been very hard to characterize what causes this bug. I don't know how to tell you to reproduce it, but it is very serious. I have been able to find a discussion using google about this exact bug and no one could really find a workaround. I recently had to change the way our project was structured get things to compile. Without the changes, we could never get errors out. I am fearful that we might add some code that leads to a situation where we can't figure out a way to restructure things so we can get it to compile. If you want to discuss this with me, please feel free to contact me. If we have to, we might be able to figure out a way to obfuscate our code so we could give it to you (no guarantees). This is a potentially lethal bug for us. Thanks, E. Harold Williams P.S. some links for other people with this bug: http://dev.eclipse.org/newslists/news.eclipse.helpwanted/msg00102.html http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg06210.html http://www.brunningonline.net/simon/blog/archives/001748.html
What build are you using? Is it 100% reproducable? Does it fix it if you remove the .index files in .metadata\.plugins\org.eclipse.jdt.core and you restart your workspace? If it is reproducable, can you provide a test case that we could use to reproduce it?
This is the same for me. Sometimes, some classes cannot be compiled and the compiler says "import x.y.z cannot be resolved" even if class "x.y.z" is included in classpath. Workarounds are : - when "x.y.z" is in a library, delete this library from classpath and add it again in classpath ; - move the line "import x.y.z" in source, or add a blank space after it But the problem occurs again after a while :-(
Please reopen with build ID and steps to reproduce the problem.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
