Hans Dockter wrote:
On Oct 1, 2009, at 9:00 AM, Adam Murdoch wrote:
Steve Appling wrote:
On a related topic, I really don't like all of the script cache
information to be stored under the user home directory. It seems
that putting this under a .gradle in the root project would be
better. That way the script caches go away when a project
directory is deleted. I currently have 745 directories directly
under my home/scriptCache directory.
Is it the fact that the scripts are cached under ~/.gradle that you
don't like, or the fact that they aren't being cleaned up when they
are no longer needed?
It is really just that they are never cleaned up that bothers me.
I think we have a similar problem under ~/.gradle/wrapper and
~/.gradle/cache.
There's a few problems with moving the scripts to the root project
dir:
- It doesn't solve the problem for ~/.gradle/wrapper and
~/.gradle/cache.
- It doesn't solve the problem for scripts which are compiled
before we know the root project dir, such as init scripts.
- It doesn't work for read-only workspaces.
There may not be quite as many files under ~/.gradle/wrapper and
~/.gradle/cache, but they take up much more space. It would be nice
to come up with a solution which cleaned up every thing we cache.
Some possible solutions:
- A task or command-line option which garbage collects ~/.gradle.
- The gradle command periodically garbage collects ~/.gradle, based
on some threshold. This could be number of invocations since last
garbage collect, time since last garbage collect, total size of
~/.gradle, or free disk space.
I think we should provide both, 1 and 2.
- We garbage collect a cache whenever we write to it (no more than
once per build).
What would be the criteria for cache elements being garbage collected
(cached build scripts, wrapper distributions)? Would be write some
timestamp file when the cached script or the wrapper is distribution
is being used and based on that define a GC policy?
Some options:
1. Record when each thing is used, and when garbage collecting discard
all things which have not been used within a certain threshold.
2. Record which builds use each thing, and when garbage collecting
discard all things not used by any build or whose builds no longer exist.
Option 2 has the benefit of only requiring an update of this meta-info
when the cache changes, whereas option 1 requires an update on each access.
- Don't cache anything under ~/.gradle. For example, store
everything under the root project dir, including the ivy cache. For
those things where we don't know the root project dir, store in a
.gradle dir in the directory containing the thing.
I would have said that I prefer this, but it doesn't handle read
only workspaces or init scripts. I don't know how important this is.
I'm not sure either. Maybe we don't care about this. We could always
add a command-line/init script option to let you specify the cache
dir, for this situation.
One other argument for using ~/.gradle as the location for metadata is
that some people have complained about having yet another metadata
directory there project. They perceive it as pollution.
True.
I can't see a really strong argument either way for ~/.gradle or for
$rootProjectDir/.gradle. Provided there aren't .gradle directories
scattered all through my source tree, I don't really care either way.
This solution also will duplicate the downloaded ivy files for
different projects, which is in line with my desire to keep project
information together, but will slow things down in general :(.
You would pay a one-off cost for each dependency per build, which
might not be too bad. Moving the ivy cache to $rootProjectDir/.gradle
has some advantages,
One advantage of this is to be able to delete a project specific ivy
cache vs. deleting the whole ivy cache.
This is appealing for automated builds, such as CI builds. If the ivy
cache were in $rootProjectDir/.gradle, we could easily extend '--cache
rebuild' to discard the ivy cache as well.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
