#1000159
- Created on2010-09-09 00:33
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
No resource at when loading dependency file (Scala builder)
I'm getting the following assertion error when Eclipse loads the dependency file. One dependecy fails (always the same, and the file exists). The required file is the first classfile to be resolved, and before that all source files resolve correctly. It makes me think that Eclipse hides that resource for some reason. Funny thing is, the whole build/quick/classes/compiler directory is missing from the Project Explorer. Could it be because it appears in the Java build path?
java.lang.AssertionError: assertion failed: No resource at "/Users/dragos/workspace/git/scala/build/quick/classes/compiler/scala/tools/nsc/Interpreter$Request$$anonfun$onErr$1$1$$anonfun$apply$15.class"
at scala.Predef$.assert(Predef.scala:91)
at scala.tools.eclipse.util.EclipseResource$.fromString(EclipseFile.scala:41)
at scala.tools.eclipse.ScalaProject$$anonfun$prepareBuild$1.apply(ScalaProject.scala:406)
at scala.tools.eclipse.ScalaProject$$anonfun$prepareBuild$1.apply(ScalaProject.scala:406)
at scala.tools.nsc.dependencies.Files$FileDependencies$$anonfun$readFrom$1.readLines$1(Files.scala:124)
at scala.tools.nsc.dependencies.Files$FileDependencies$$anonfun$readFrom$1.apply(Files.scala:144)
at scala.tools.nsc.dependencies.Files$FileDependencies$$anonfun$readFrom$1.apply(Files.scala:115)
at scala.tools.nsc.dependencies.Files$class.readFromFile(Files.scala:172)
at scala.tools.nsc.Global$dependencyAnalysis$.readFromFile(Global.scala:465)
at scala.tools.nsc.dependencies.DependencyAnalysis$class.loadFrom(DependencyAnalysis.scala:76)
at scala.tools.nsc.interactive.RefinedBuildManager.loadFrom(RefinedBuildManager.scala:340)
at scala.tools.eclipse.ScalaProject.prepareBuild(ScalaProject.scala:406)
at scala.tools.eclipse.ScalaBuilder.build(ScalaBuilder.scala:54)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Leave a comment
on 2010-09-09 18:05 *
By
Are you using the build/quick/classes directory as your Eclipse output folder?
on 2010-09-09 22:03 *
By Iulian Dragos
Yes, I am using build/quick/classes/compiler as both the output and part of the build path. Is that a big no-no?
on 2010-09-09 22:03 *
By Iulian Dragos
Yes, I am using build/quick/classes/compiler as both the output and part of the build path. Is that a big no-no?
on 2010-09-09 22:26 *
By
Yes if you have incremental building enabled and also recompile from the command line. Depending on the circumstances Eclipse will either see classfiles disappearing and trigger recompilation to replace them. Or maybe it won't (because the workspace hasn't been refreshed, so it's view of the filesystem is out of sync with reality) and it will expect classfiles to exist which the command line build had removed.
I'm not 100% sure that this is the explanation of the problem you're seeing, but it seems quite likely.
I'm not 100% sure that this is the explanation of the problem you're seeing, but it seems quite likely.
on 2010-09-09 22:34 *
By Iulian Dragos
It happens when the build manager loads the dependency file ".scala_dependencies". That file refers to classfiles under build/quick/classes/compiler. The file exists on disk, but refreshing Eclipse does not help. Additionally, the whole directory is missing in the project explorer, which makes me thing this may be a 'feature'. Anyway, it's very confusing. The net effect is that the builder does not do anything, because it fails loading the dependencies.
on 2010-09-09 22:45 *
By
As you guessed, it is an Eclipse feature that the output folder (wherever it is) is hidden in the Package Explorer.
The assertion is telling you that Eclipse doesn't know that the file exists ... if it's there on the filesystem, then that's a refresh issue. If you're doing command line builds as well as incremental ones, then that's not surprising.
Basically the issue is that Eclipse expects to be in control of the output folder, and in your case is isn't. I'd recommend either turning off automatic building, or using an output folder that's separate from your ant build directory.
The assertion is telling you that Eclipse doesn't know that the file exists ... if it's there on the filesystem, then that's a refresh issue. If you're doing command line builds as well as incremental ones, then that's not surprising.
Basically the issue is that Eclipse expects to be in control of the output folder, and in your case is isn't. I'd recommend either turning off automatic building, or using an output folder that's separate from your ant build directory.
on 2010-09-09 23:00 *
By Iulian Dragos
I refreshed the project, and that did not help. It fails even before it tries building anything, just when reading the configuration file. The configuration file contains a reference to a classfile in build/quick/classes/compiler. I don't see any connection with building outside Eclipse (though I am guilty of that ;-)), since ant does not dump a .scala_dependencies file. Therefore, it is written by Eclipse, and later it can't be properly parsed.
I removed the directory from the build path, but it still is the output directory. The same thing happens. I wonder if it ever worked. If the output folder is unavailable in the Eclipse File System, then this dependency file will never be parsed correctly.
I removed the directory from the build path, but it still is the output directory. The same thing happens. I wonder if it ever worked. If the output folder is unavailable in the Eclipse File System, then this dependency file will never be parsed correctly.
The .scala_dependencies file was written by the build manager. However, your external builds have invalidated it by removing a classfile which is expected to be present. You can workaround the problem by deleting the .scala_dependencies file (it will be recreated) or doing an Eclipse clean (the same).
Fixing the problem properly involves throwing an exception rather than asserting. That exception then needs to be handled gracefully in the build manager (currently I think it would fail in exactly the same way that it does with the assert).
If you want to take a look at the assert I'll have Eclipse throw a FileNotFoundException.
Fixing the problem properly involves throwing an exception rather than asserting. That exception then needs to be handled gracefully in the build manager (currently I think it would fail in exactly the same way that it does with the assert).
If you want to take a look at the assert I'll have Eclipse throw a FileNotFoundException.
on 2010-09-09 23:41 *
By
Sorry, I meant "If you want to take a look at the build manager I'll have Eclipse throw a FileNotFoundException".
on 2010-09-10 15:59 *
By Iulian Dragos
Miles, the classfile is there. It exists, I refresh the project, I did everything I know to make Eclipse aware of this fact.
Regarding what to do, I think that file is under the control of the plugin, so it should not be handled by the build manager, which has only to actions: loadFrom and saveTo. It would be unorthodox to delete the file during loadFrom, if the file contains errors. Currently the plugin tries to reload it each time, and that leads to no progress.
Regarding what to do, I think that file is under the control of the plugin, so it should not be handled by the build manager, which has only to actions: loadFrom and saveTo. It would be unorthodox to delete the file during loadFrom, if the file contains errors. Currently the plugin tries to reload it each time, and that leads to no progress.
on 2010-09-11 21:24 *
By
I don't dispute that the file is there on the real filesystem. But for whatever reason, Eclipse's virtual filesystem isn't aware of it. That's not something under my control. It's possible that you've found a generic Eclipse bug, but most likely this is expected behaviour when the workspace is mutated outside of Eclipse, which is what you've done.
All I can do here is turn the assert into an exception throw, but in that case the build manager will need to recover, presumably by recreating the classfile in question.
As to deleting .scala_dependencies file goes, this is done by the SDT whenever you do an Eclipse project clean. I wasn't suggesting that the build manager should do it. I was suggesting that if it's corrupted and for whatever reason you don't want to clean the project you could delete the file by hand.
All I can do here is turn the assert into an exception throw, but in that case the build manager will need to recover, presumably by recreating the classfile in question.
As to deleting .scala_dependencies file goes, this is done by the SDT whenever you do an Eclipse project clean. I wasn't suggesting that the build manager should do it. I was suggesting that if it's corrupted and for whatever reason you don't want to clean the project you could delete the file by hand.
on 2010-09-15 20:09 *
By
I've committed what should be a fix for this in revision:bd9f07cbbf177684d732312547412819187879a4 ... let me know how you get on with it.
Nb. if you modify Eclipse's output directories outside of Eclipse it's still quite likely that you will see peculiar behaviour, so it's best to avoid doing that if possible.
Nb. if you modify Eclipse's output directories outside of Eclipse it's still quite likely that you will see peculiar behaviour, so it's best to avoid doing that if possible.
Updating tickets (#3255, #3262, #3271, #3277, #3279, #3287, #3313, #3317, #3318, #3320, #3329, #1000000, #1000002, #1000004, #1000005, #1000007, #1000011, #1000013, #1000018, #1000019, #1000020, #1000022, #1000023, #1000024, #1000025, #1000026, #1000028, #1000031, #1000033, #1000034, #1000037, #1000039, #1000040, #1000041, #1000057, #1000058, #1000060, #1000061, #1000063, #1000064, #1000065, #1000067, #1000070, #1000073, #1000076, #1000080, #1000082, #1000083, #1000084, #1000085, #1000087, #1000088, #1000089, #1000090, #1000092, #1000093, #1000094, #1000095, #1000097, #1000102, #1000104, #1000106, #1000108, #1000110, #1000111, #1000116, #1000124, #1000126, #1000127, #1000129, #1000132, #1000133, #1000136, #1000139, #1000143, #1000144, #1000145, #1000148, #1000149, #1000152, #1000154, #1000155, #1000157, #1000158, #1000159, #1000161, #1000169, #1000170, #1000172, #1000174, #1000176, #1000178, #1000179, #1000183, #1000185, #1000188, #1000189, #1000192, #1000196, #1000198)
on 2014-10-20 23:43 *
By Iulian Dragos
Eclipse version changed from Galileo to Luna - Eclipse 4.4
Version changed from 1.0.0-SNAPSHOT to 3.0.4-211
Status changed from Test to Fixed