Community
Participate
Working Groups
I can't build my project. I always get this error message: The project was not built since it is inconsistent. Ensure no other tool is browsing the output directory, then try refreshing this project and rebuilding it. I am using 2 environments both with F1. Both give the same problems: Nt 4.0: entire Eclipse project is in Clearcase (using a dynamic view). Clearcase symbolic links are used to map the source and dependent jars into the project directory. Since the whole project is in the Clearcase view, the build output directory is of course managed by Clearcase. Solaris/motif: Eclipse project is outside of clearcase. Symbolic links are used to map the source from the clearcase view into my eclipse project. The build output does not go to a Clearcase managed directory. A similar report was mentioned in Bug 13721 which was then resolved as a duplicate of Bug 13682. The latter has been resolved as fixed but this problem does not seem to have been addressed. I have tried installing the Clearcase plugin that comes with Rationals XDE but that made no difference. I found similar reports specifically related to using Clearcase at: http://www.rational.com/HyperMail/cciug/hypermail/0205/0694.html http://sourceforge.net/tracker/index.php? func=detail&aid=550991&group_id=50595&atid=460297 http://dev.eclipse.org/newslists/news.eclipse.tools/msg20319.html http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg00427.html
I have everything building again now be excluding some clearcase related files from the build resource copy.
Neil, I haven't been following this bug closely, but I suspect the problem is clearcase dynamic views, which you mention you are using. There is a known problem with integration of CC dynamic views and eclipse: your view directory gets updated "under the covers" by CC and eclipse isn't informed that its out of date. Also, the CC plugin isn't informed by the CC view manager thingy. The plugin that DJ mentioned in the other bug report that looks for out of sync files was created for this particular problem. I am not sure what else has been done on the CC front for that case. I think symbolic links are problematic as well, but I am out of my area here. I am moving this back to platform/core because I don't believe its a JDT bug.
Also Neil, note there are a variety of ways that a resource can become out of sync with the file system. I think this is part of the confusion with this bug report's history: the outward behaviour is the same but the cause is likely completely different. This has caused some unfortunate swirl on our part, and I'm sure frustation on your part.
I believe the jdt.core logs a more detailed internal error message (stack trace) to the .log file when the inconsistent project error is reported to the user. Can you check to see if you have an associated log message, and post it here? Thanks.
The complaint coming from JDT/Core builder is coming from the fact some files/folders could not be deleted from the output folder. Usually it means that some resources were inconsistent or someone was holding onto them... In all these situations, a stack trace should be present in the log entry... If necessary, we can instrument some more the JDT/Core plug-in for easing debugging this issue. Please let us know...
I can workaround with the following build exclusions: *.launch, .cmake*, *.contrib, *.keep, findmerge* Stacktrace follows: java.version=1.4.0 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_CH Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\things\eclipseData -feature org.eclipse.platform -install file:C:/Program Files/eclipse/ !ENTRY org.eclipse.jdt.core 4 4 Mai 28, 2002 10:05:31.206 !MESSAGE JavaBuilder handling ImageBuilderInternalException !STACK 1 org.eclipse.core.internal.resources.ResourceException: Problems encountered while copying resources. at org.eclipse.core.internal.localstore.FileSystemResourceManager.copy (FileSystemResourceManager.java:67) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:355) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:372) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder$3.visit (BatchImageBuilder.java:131) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:58) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:40) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.copyExtraResourcesBack (BatchImageBuilder.java:116) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.scrubOutputFolder (BatchImageBuilder.java:88) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build (BatchImageBuilder.java:33) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll (JavaBuilder.java:174) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build (JavaBuilder.java:99) at org.eclipse.core.internal.events.BuildManager$2.run (BuildManager.java:383) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:802) at org.eclipse.core.runtime.Platform.run(Platform.java:416) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:119) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:173) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:183) at org.eclipse.core.internal.events.BuildManager$1.run (BuildManager.java:143) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:802) at org.eclipse.core.runtime.Platform.run(Platform.java:416) at org.eclipse.core.internal.events.BuildManager.basicBuild (BuildManager.java:157) at org.eclipse.core.internal.events.BuildManager.build (BuildManager.java:208) at org.eclipse.core.internal.resources.Workspace.endOperation (Workspace.java:733) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1366) at org.eclipse.ui.actions.WorkspaceModifyOperation.run (WorkspaceModifyOperation.java:78) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run (ModalContext.java:98) !ENTRY org.eclipse.core.resources 4 1 Mai 28, 2002 10:05:31.222 !MESSAGE Problems encountered while copying resources. !SUBENTRY 1 org.eclipse.core.resources 4 274 Mai 28, 2002 10:05:31.222
Neil, can you please try this again in F2? Make sure you attach the complete log, because it appears that the log above is cut off at the bottom.
Initial impression of F2 is that the problem has been fixed. Will give it a bit more time.
Created attachment 1583 [details] log files
The attached log file shows the problem still happening in GM1. I hadn't had any problems for a while since I didn't have any of the offending files in my source. Again I can stop the error by excluding those source types. i.e. *.launch,.cmake*,*.contrib,*.keep,findmerge* The clearcase/samba configuration is as described in bug 16280.
Just tried Rational's Clearcase plugin (2.0.18) with release 2.0. Problem still exists.
This is basically the same problem as bug 16280. I investigated further and found that the timestamps differed by 1 second. My "nearly the same" hack for bug 16280 didn't affect this because the "out of sync" comparison is done in several different places.
It seems the fault here lies with clearcase, providing inconsistent timestamps (see bug 16280). However, the eclipse user would be spared a lot of pain if the compiler would just overwrite the class file rather than aborting.
*** Bug 24291 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 16280 ***
