Incremental API and disk format for task caching #210
Conversation
Includes an incremental implementation of gwtincompatible stripping and closure bundling.
build-caching/src/main/java/com/vertispan/j2cl/build/DefaultDiskCache.java
Show resolved
Hide resolved
build-caching/src/main/java/com/vertispan/j2cl/build/TaskScheduler.java
Outdated
Show resolved
Hide resolved
j2cl-tasks/src/main/java/com/vertispan/j2cl/build/provided/J2clTask.java
Outdated
Show resolved
Hide resolved
build-caching/src/main/java/com/vertispan/j2cl/build/LocalProjectBuildCache.java
Show resolved
Hide resolved
| Files.createDirectories(localTaskDir); | ||
| Files.write(localTaskDir.resolve(timestamp), Collections.singleton(taskDir.toString())); | ||
|
|
||
| Files.list(localTaskDir).sorted(Comparator.<Path>naturalOrder().reversed()).skip(5).forEach(old -> { |
There was a problem hiding this comment.
Let's make this const configurable, as a separate PR
| @@ -16,6 +16,9 @@ public abstract class AbstractCacheMojo extends AbstractMojo { | |||
| @Parameter(defaultValue = "${project.build.directory}/gwt3BuildCache", required = true, property = "gwt3.cache.dir") | |||
| private File gwt3BuildCacheDir; | |||
|
|
|||
| @Parameter(defaultValue = "${project.build.directory}/j2cl-maven-plugin-local-cache", required = true) | |||
There was a problem hiding this comment.
so now we have j2cl-maven-plugin-local-cache and gwt3BuildCache, isn't this redundant?
There was a problem hiding this comment.
It is a good question, but they serve different purposes. The gwt3buildCache (should be renamed someday) is explicitly able to be shared between projects, and holds build output that could be reusable across modules, projects. On the other hand, the local cache only is meant to be specific to a single module, and reflects the last N (N=5 above, but you suggest we change this) rebuilds. Those last rebuilds are references to the gwt3BuildCache, so we know what recent rebuilds were appropriate for this module, and in what order they happened.
If the local cache was global, you could work on project A for a day, then project B for a day, then try to update A and it would try to incrementally rebuild from B's last builds. This won't magically protect you from changing git branches, but in theory tasks that are able to be incremental will notice if too much has changed to be incremental and will do a fresh build.
The Task.execute() call now can examine old results and changes to inputs to make decisions about incrementally building new outputs more efficiently.
Fixes #176