Community
Participate
Working Groups
20020115 This is the second time I have found myself in this state, and I know that Veronika got into this state once also. Neither of us had ever seen this state before 20020115. Originally, we were not sure what caused the state, but I think now that it may have something to do with loading from stream. Please see Bug: http://dev.eclipse.org/bugs/show_bug.cgi?id=7894 which happened immediately before I entered this state for the second time. The symptoms of the wierd state are: - There's an error marked against the project you were working in - The error message in the task view says the following: "The project was not built since it is inconsistent. Refresh this project then rebuild it" - You try to refresh from local and then rebuild, but the error does not go away - You try exiting eclipse and restarting/rebuilding, but the error still stays - The only way we have discovered to get rid of the error and get out of the wierd state is to delete the bin directory and rebuild. I looked to see if anyone else had reported this, and the closest Bug report I can see is the following, but it may not be related: http://dev.eclipse.org/bugs/show_bug.cgi?id=5552
Some notes from Tim Francis indicating this is not a VCM bug. Have emailed JDT-Core. Moving to JDT-Core. From Tim: My pop-up action, which I've been testing with the last stable build (20011219) consistently and repeatedly causes the problem you report in bugzilla. On some projects it works fine, but I have one project for which the problem is 100% reproducible, without using CMVC. The action in question simply locates a source jar, unzips it, modifies the project's classpath, refreshes and rebuilds. Once the project gets into this state, I can't fix it - contrary to the message text, refreshing and rebuilding do not help. If you need a reproducible testcase to help you narrow the problem down, let me know and I'll be happy to send it to you. I did do some investigation myself, and the error appears to be emitted from org.eclipse.jdt.internal.core.newbuilder.JavaBuilder, in the build method. There are two catch blocks there, for CoreException and ImageBuilderInternalException, and both add the message we're both seeing to the task list. This makes me think the problem is much more generic than the message implies, it's really just a catch-all "the Java builder had problems" message, and unfortunately I don't see any logging of what that root problem is.
Tim - did you try going to the file system, deleting your project's "bin" directory, and rebuilding the project? This hack seems to work for both Veronika and I. (and it has worked twice for me). Anyhow, the hack lets you keep your workspace.
FYI, this problem still exists in 20020125. I just got it again. Seems to happen when I make a change to the "COM" class in SWT. Then I delete my SWT project's 'bin' directory in my workspace, and I can recompile the project, and all is well again. KJ, if you want me to run with any debug code, or call you when it happens again, please let me know.
Please let me know if this still happens with a new build (from the Integration build 20020129 on).
Something to keep in mind. If you have explorers or dos boxes open, whose current directories are inside the bin directory, then full builds will fail when they try to wipe the bin directory. Also please enable builder tracing... follow the instructions below to set: org.eclipse.jdt.core/debug/builder=true All other subtraces should be set to false. --------------------- From build 20011107 on, we have released a ".options" file inside our plugin which can be used as a template for activating traces inside the JDT/Core area. It is using the generic Eclipse debug mode which means that you need to perform the following steps before seeing the JDT/Core traces: Copy our .options template file located at <installLocation>/plugins/org.eclipse.jdt.core/.options up to the <installLocation> next to the Eclipse.exe file. Start Eclipse in debug mode using the -debug extra command line argument. Example of an JDT/Core .options file: org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/indexmanager=true org.eclipse.jdt.core/debug/compiler=true org.eclipse.jdt.core/debug/javamodel=true org.eclipse.jdt.core/debug/javadelta=true org.eclipse.jdt.core/debug/hierarchy=true org.eclipse.jdt.core/debug/builder=true Debug tracing the JDT/Core can lead to a lot of messages to be dumped out, therefore you can further edit the .options file in order to turn off uninteresting traces. Here is what can be selectively chosen: org.eclipse.jdt.core/debug/indexmanager=true Enable tracing of background indexing process. It will indicate all interactions with the indexer, either when modifying the index files and or performing queries in them. org.eclipse.jdt.core/debug/compiler=true Enable tracing of all actual Java compiler activity. org.eclipse.jdt.core/debug/javamodel=true Enable tracing of the Java Model lazy populating. It will indicate when actually opening/closing a Java element. org.eclipse.jdt.core/debug/javadelta=true Enable tracing of the Java element deltas which are fired to listeners. org.eclipse.jdt.core/debug/hierarchy=true Enable tracing of the type hierarchy computation. org.eclipse.jdt.core/debug/builder=true Enable tracing of the Java builder activity. The Java builder is driving the incremental recompilation aspects, and this trace can be used to understand why a given file actually got triggered for recompilation. Note that this trace is not yet fully implemented given the Java builder is under rework.
The Java debug options gave me no additional info - but I tried the 20020129 integration drop, and it seems to have fixed the problem. I now get an error in the project that "This resource "(a non-java file in my source directory)" is a duplicate and was not copied to the output folder". This is much better than the previous error - mostly because it's just an error, but doesn't appear to stop the rest of the build, but also because it clearly identifies the problem, so I can now go to the root cause and fix it properly. My suspicion is that this was the problem all along, and I'm just getting a much better error message now. Anyway, thanks for your help.
You're right Tim, duplicates (java files as well as other resources) were not detected before 0129. The catch all error is really only intended to catch the case of an explorer or dos-box with a current directory inside the output folder... a refresh + rebuild works in the cases we have tested. All other CoreExceptions are internal bugs which we need to track down & fix.
Closing.
