Community
Participate
Working Groups
Reported to me this morning, a few files are having the same 'resource already exists on disk' problem, a stack trace for one of them is: org.eclipse.core.internal.resources.ResourceException: Resource already exists on disk: '/org.eclipse.virgo.kernel.deployer.dm/target/classes/META-INF/spring/deployer-dm-context.xml'. at org.eclipse.core.internal.localstore.FileSystemResourceManager.copy(FileSystemResourceManager.java:224) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:548) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:526) at org.eclipse.ajdt.core.builder.AJBuilder$1.visit(AJBuilder.java:776) at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:112) at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:64) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:82) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:86) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:127) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:74) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:110) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:94) at org.eclipse.ajdt.core.builder.AJBuilder.copyResources(AJBuilder.java:791) at org.eclipse.ajdt.core.builder.AJBuilder.build(AJBuilder.java:217) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
My guess is that what is happening here is that there is a build occurring outside of Eclipse that is placing the resources on the disk. But, there is no refresh occurring inside of Eclipse, so the AJBuilder assumes that there is no file at the specified location, when there actually is. The solution seems to be to do a resource refresh on the target before trying to copy. However, a resource refresh is a non-trivial action, so I'd like to avoid doing them if I don't have to. But, it seems like this will be necessary.
I guess another possibility would be to do the copy inside of a try statement, and in the catch block, look for the specific resource exception. If so, then we can just swallow the exception, if it is a different exception, then we rethrow.
The solution that I have now is to log the exception to the AJDT Event trace, but to otherwise ignore it. I will be committing shortly when some tests are passing.
Fix committed.
