[GRADLE-145] Cache the build source jar. Created: 06/Jul/08 Updated: 04/Jan/13 Resolved: 08/Nov/08 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 0.2 |
| Fix Version/s: | 0.5 |
| Type: | Improvement | ||
| Reporter: | Hans Dockter | Assignee: | Hans Dockter |
| Resolution: | Fixed | Votes: | 1 |
| Description |
|
The build sources are changed usually much less frequently compared to executions of the build. Caching the jar would improve the build execution speed tremendously. The problem is how to invalidate the dag. Per default we would check if any main/groovy, main/java, main/resources, test/groovy, test/java, test/resources. This should be good enough for most use cases. Additional one can provide an invalidation script where a custom invalidation policy can be defined. The build source jar caching would obey to the same cache command line options than the build script cache. |
| Comments |
| Comment by Russel Winder [ 26/Oct/08 ] |
|
The fact that buildSrc gets completely rebuit every time any action is undertaken in the Gradle source is more than just an anti-optimization, it is a complete irritation. Performing: gradle clean gradle clean should never require a rebuild of buildSrc for the second execution where currently it does. Gradle should be able to deduce that buildSrc is up to date, if it cannot how can it claim to be a good dependency calculation system? To be honest I would say that currently the Gradle build is broken because of this. |
| Comment by Hans Dockter [ 08/Nov/08 ] |
|
The situation can be quite complex. What if the build of the build sources depends on a property they obtain from the network. One problem of this issue is cache invalidation. We have implemented this issue now with a default invalidation strategy. We need to provide for 0.6 hooking of custom invalidation strategies. |