Community
Participate
Working Groups
build R2.1 Loaded a project from CVS that contained a linked file. The linked file was created using a path variable. The path variable is not defined in my workspace. The project was not built due to "The location for .../linkedFile could not be determined because it is based on an ndefined path variable.". I don't see why an invalid linked resource should prevent the project from being built.
This is happening in the java builder. To generalize this problem, if a CoreException is thrown while copying a single resource, should the whole build be aborted? Perhaps you could put an error marker on that resource and continue with copying the other resources? Here is a sample stack trace: org.eclipse.core.internal.resources.ResourceException: The location for /t/abc could not be determined because it is based on an undefined path variable. at org.eclipse.core.internal.resources.Resource.checkCopyRequirements(Resource.java:241) at org.eclipse.core.internal.resources.Resource.assertCopyRequirements(Resource.java:134) at org.eclipse.core.internal.resources.Resource.copy(Resource.java:501) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder$3.visit(BatchImageBuilder.java:192) at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:50) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:76) at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:80) at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:119) at org.eclipse.core.internal.resources.Resource.accept(Resource.java:60) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.copyExtraResourcesBack(BatchImageBuilder.java:170) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:113) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:37) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:194) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:122) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:427) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:889) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:125) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:181) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:191) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:151) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:889) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:165) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:243) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:212) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:884) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1600) ...
Can we still blame such a resource for which the variable path isn't bound ?
I think yes, the relevant information for the user is that the linked resource was not copied to the build output.
What's supposed to happen when 50 or 500 resources cannot be copied because of the same error? We treat all classpath errors (including undefined variables) as major build failures since they can affect so many resources in the project. Producing hundreds of the same error won't make things better.
You may have a point here. In my case the linked resource was just an "extra" and not an essential part of the project. In the general case linked resources would point to actual build input or may even be the only build input. If we think there can be a large number of linked resources on the classpath then it's probably ok or even desirable to abort building the project.
Closing. Unless we can come up with a way to avoid the 50/100 identical error case, I think we'll leave this as is.
