Summary: | Wierd state: Project not built because inconsistent. | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Carolyn MacLeod <carolynmacleod4> |
Component: | Core | Assignee: | Kent Johnson <kent_johnson> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | francis |
Version: | 2.0 | ||
Target Milestone: | 2.0 M3 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Carolyn MacLeod
2002-01-18 14:24:38 EST
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. |