SBT reload fails on SNAPSHOT which are republished locally *while SBT runs* #892
Comments
|
sbt is getting a |
|
I see — no workaround possible for SBT then? Since you closed, I assume not. |
|
seems to be a known problem http://stackoverflow.com/questions/17060411/failed-to-load-resources-in-jar-file-when-jar-file-is-replaced |
|
@ritschwumm, thanks! One answer suggests that throwing away the classloader would help, which would make sense. Is SBT reusing classloaders? Could they be thrown away on reload, at least if the underlying files changed timestamp (and/or it's a SNAPSHOT)? |
|
sbt doesn't reuse the plugin classloader, but it doesn't discard the old project until the new one has successfully loaded. It will fall back on the old one if the new one fails and you select In general, sbt can cache/reuse class loaders, but it only currently does this for Scala jars, the loaders are behind |
|
Ouch, this sucks :( |
|
+1 |
|
This makes testing newly published plugins locally, in a "real" SBT project (e.g. not a |
See details in sbt/sbt#892. We were getting same error because the plugin comes from a jar. Now, we lie to sbt, we present the plugin as a project with classes directory which just happens to have a dependency that brings in the shaded sbt plugin we want.
To work around sbt/sbt#892 again.
To work around sbt/sbt#892 again.
To work around sbt/sbt#892 again.
Including a simplification of the work around for sbt/sbt#892
Including a simplification of the work around for sbt/sbt#892
Including a simplification of the work around for sbt/sbt#892
Alright, so I'm pretty confident with this at the moment, and quite happy with it. Much of it was mimicking what Alex did in bloop-core by just ripping it all out. As I stated in the initial description, it seems that the entire notion of having the sbt-bloop-build-naked and the bloop-shaded-plugin is primarily to dogfood itself in a way that doesn't conflict with the issue that is outlined in sbt/sbt#892. Maybe at one point in time when we were rapidly developing the sbt plugin and build and always wanting to dogfood those changes this may have been worth it, but I don't think it is anymore. The entire meta-meta build can just be thrown away if we get rid of the idea of wanting to do this. Instead, we just ensure that we publish sbt-bloop before situations where we want to ensure we're using that. This is primarily when we're running the frontend tests and we an the Bloop definitions of the projects in the frontend resources and when we're running buildpress. In both of these scenarios we just publish sbt-bloop first, and it works the same way. Benchmarks will also work exactly the same as the version is passed directly to it that we're using. We included the sbt-bloop-build-naked there before, but from my understanding it was again only to dogfood the bloop generation when we can just use the one we just published. So to outline the changes, this - gets rid of the sbt-bloop-build-naked - gets rid of the bloop-build-shaded-plugin - benchpress is still able to run fine - frontend test resources are still able to be generated fine - tests all still pass - the build is way less crazy The main thing we lose out on is: We no longer dogfood the absolute latest changes This is a tradeoff I'm 100% ok with.
I'm developing a SBT plugin and testing it by reloading in a project using it. The reload however fails, complaining about corruption of the plugin JAR file, and I must exit and re-enter the client SBT project; this happened with SBT 0.13.0 in the client, and 0.12.4 in the SBT used for development.
The first time, the client SBT complained that it can't find
sbt/sbt.pluginswithin the JAR. But unzip confirms the entry is there; exiting and re-entering SBT in the client project fixes the problem. The second time, the error was different, but againunzip -tconfirms that the JAR is fine. The third time, the error was yet different, but again about ZIP corruption.Note that before the failed reload, lsof reveals that SBT has two file descriptors pointing at the JAR of the plugin, while afterwards it has three or four file descriptors. My suspect is that it does not reopen the JAR file from scratch, but tries to reuse some old info about it.
To support this hypothesis, this only happens if settings from the plugin are actually used (by putting
seq($thisPluginSettings: _*)in build.sbt).Steps to reproduce in my case:
Error message 1:
Error message 2:
The text was updated successfully, but these errors were encountered: