Update cache not working in dev mode

[jroper]

On master, the update cache is not working.

To illustrate, run chirper with Lagom 1.0.0-M1, using runAll. Then stop it. Then run runAll again. On the second run, every server should just start, without doing any resolving.

However, if using master, every project needs to be resolved every time you run runAll. Somehow the update cache isn't working.

Further more, it appears to be updating every project twice in parallel - this could explain why the update cache isn't working, the parallel runs are probably invalidating each other:

[info] Updating {file:/home/jroper/src/activator-lagom-java-chirper/}front-end...
[info] Resolving org.scala-lang#scala-library;2.11.7 ...
[info] Updating {file:/home/jroper/src/activator-lagom-java-chirper/}front-end...
[info] Resolving jline#jline;2.12.1 ...

This makes starting chirper very slow every time, not just the first time.

[jroper]

Ok, so the problem here is that Defaults.baseClasspaths is being redefined in the DevRuntime scope for every project many times (the many times is not causing the problem, but it's just unnecessary). This means the update task, which should not be scoped to a configuration, is being redefined in the DevRuntime configuration, so when externalDependencyClasspath in DevRuntime is executed, for example, it causes update in DevRuntime to also be executed, which since it's been defined explicitly at that scope now, is considered by sbt to be a different task to update, and so sbt runs both update and update in DevRuntime, usually concurrently, and they stomp on each other.

We must not redefine all the Defaults.baseClasspaths in a different scope, it's probably going to break many other things, not just this.

I think the sbt plugin refactoring has to be backed out, I can't see any way to fix it. What I'd really like to see is if we had something like:

val DevRuntime = Config("dev-mode") extends Runtime

Then we can:

libraryDependencies += component("lagom-reloadable-server") % DevRuntime

And then we can just interrogate the update report for the classpath in the DevRuntime scope, and that should bring in all the project dependencies, not just the dev runtime scoped ones (since dev runtime extends runtime), and then we don't have to use any concatenation anywhere, no need to go and also get the Runtime classpath. In fact, if you ever do ++ on a classpath, that should be an immediate alarm bell - we should never do that, we should let Ivy work out classpaths. That should be a lot simpler than the current setup.

[jroper]

@dotta

[dotta]

James, thanks for raising this. I'm not sure what you mean with "I think the sbt plugin refactoring has to be backed out", but having dependencies simply scoped to DevRuntime, without redefining other tasks, is definitely a good idea to fix this issue.