Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. open a project with multiple java source files (tested on a "Dynamic Web Project" with hundreds of java source files and other resources) 2. the option "build automatically" is on 3. JDK is Java 1.5.0_16 4. open a file of your choice (java source, text file, etc.) 5. change some text (or just make the file "dirty" so you can save it) 6. choose File > Save (or CTRL+s) 7. full build is triggered (as in "clean and compile all source files in the project") More information: I'm running Eclipse 3.4, JDK 1.5.0_16, Mylyn, Subclipse, WTP + a few small plugins on Fedora Core 9 kernel version 2.6.26.3-29 I encountered this odd behavior a day ago after using Eclipse 3.4 for a few weeks. No notable prior changes to the system (except maybe upgrading from FC7 to FedoraC9). Tried a new workspace, fresh Eclipse installation, but that didn't help.
I suspect that one of the extra plugins (other than the SDK) is causing grief. Can you please try to reproduce with a plain SDK?
I didn't have time to reproduce with a plain SDK as you requested, however the problem is gone now (finally!). It seems to me that the problem was, that after someone removed a JAR dependency from the project, he forgot to fix some missing imports in a java class (testCase) that was no longer used (so most people didn't have it in their classpath and thus didn't know or care). The problems view showed this along with another error - something like "due to unsatisfied dependencies the project could not be built" or some such... I assumed this wouldn't be a problem (I mean I assumed, that one missing import would't prevent the rest of the project from being built) so I let it be - since it was only a single unimportant class / testcase. Apparently Eclipse got this "project wasn't built" error even after a full build and so tried again and again to build it... Today it finally started to annoy me more than a little, so I fixed the imports and was amazed to see the problem suddenly go away. I'm not sure whether this is a real bug or not so I'll leave the resolution to you. Anyway thanx for the reply!
(In reply to comment #2) That would still be a bug. However I cannot reproduce this behavior. If I save a X.java file in a project that has the following errors: Description Resource Path Location Type The project was not built since its build path is incomplete. Cannot find the class file for p.X. Fix the build path then try building this project Test Unknown Java Problem The type p.X cannot be resolved. It is indirectly referenced from required .class files X.java Test/src line 5 Java Problem Next time I save this X.java file, an incremental build occurs, i.e. only this file is recompiled. It would be great if you could give more information on how to reproduce this.
Jerome - I don't see how this is a bug. We detected an invalid classpath & reported the error against the project with 'The project was not built since its build path is incomplete...' If a user chooses to ignore such an error, then repeated full builds that continue to fail for the exact same reason should be expected.
(In reply to comment #4) > Jerome - I don't see how this is a bug. > > We detected an invalid classpath & reported the error against the project with > 'The project was not built since its build path is incomplete...' > > If a user chooses to ignore such an error, then repeated full builds that > continue to fail for the exact same reason should be expected. > I thought you would do a full build only if the classpath changed. If the user doesn't change the classpath, why would you do a full build? It will still be broken. Or did I miss something?
We abort the first full build because the classpath is broken & we cannot find a .class file. Since we didn't successfully build the project, there is no saved build state & we need to do another full build the next time a build is requested. We only get out of doing full builds when the classpath error is fixed & the full build is successful.
The thing is, that the full build is actually carried out every time (we have a large project, so that can take about 5 minutes. From what you wrote ("we abort the first full build") I would expect eclipse not to do the full build in the first place (seeing there's a classpath problem), but it does so every time ANYTHING changes (5 minutes in vain). Sorry if that's the normal behavior...
(In reply to comment #6) > We abort the first full build because the classpath is broken & we cannot find > a .class file. > > Since we didn't successfully build the project, there is no saved build state & > we need to do another full build the next time a build is requested. > > > We only get out of doing full builds when the classpath error is fixed & the > full build is successful. > I'm not seeing this: 1. Enable builder trace 2. Start a new workspace 3. Create a Java project 4. Add external library org.eclipse.jdt.core_3.5.0.v_914.jar 5. Add the following X.java file in the Java project: import org.eclipse.jdt.internal.core.DeltaProcessingState; public class X { public void foo(DeltaProcessingState state) { state.resourceChanged(null); } } Observe: You get 2 error markers in the Problems view 6. Make a change to X.java (add a space) 7. Save Observe: The tracing says it is doing an INCREMENTAL build
Sorry Jakub, I wasn't clear enough. Each time a build is invoked, we 'believe' the missing .class file is now available. Its possible that you've added/replaced one or several jar files, or .class files in a class folder, that could make the build succeed. As your case shows, it can take us 5 minutes to find out that it still is NOT available AND you still have an indirect reference to it.
Jerome - you're right. We're no longer doing a 'full' build, but an incremental of all source files in the project. I forgot about this change in IncrementalImageBuilder on lines 81-85 : if (this.javaBuilder.hasBuildpathErrors()) { // if a mssing class file was detected in the last build, a build state was saved since its no longer fatal // but we need to rebuild every source file since problems were not recorded // AND to avoid the infinite build scenario if this project is involved in a cycle, see bug 160550 // we need to avoid unnecessary deltas caused by doing a full build in this case See bug 160550 I'll add a new debug message for this case.
Releasd extra debug message for 3.5M3
Verified for 3.5M3
