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?
- 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.
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.
such as it gets rid of some ivy weirdness when multiple builds share
the same cache.
It would be better if Ivy could solve those problems (and it might
have improved during the last releases, I'm not sure).
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
