On 08/12/2011, at 6:34 AM, Russel Winder wrote:
> It seems that all artefacts have to be downloaded anew for every new
> version of Gradle even if the artefact had previously already been
> downloaded. This means Gradle is still maintaining independent per
> version repository caches. I had tho
It seems that all artefacts have to be downloaded anew for every new
version of Gradle even if the artefact had previously already been
downloaded. This means Gradle is still maintaining independent per
version repository caches. I had thought the intention was to move to
the more Maven-like sing
> What kind of management does it need to do? i.e. what would very good
> management look like?
I've already given some thoughts on this to Adam in the Gradle issue tracker
issue about 'runaway daemon'.
But this is a hard question. I don't have the answer, just some random thoughts
:-)
What I
On 06/12/2011, at 6:58 PM, Kris De Volder wrote:
>> So what happens to this large chunk of memory we've claimed from the
>> OS but don't go near again? My point was that the OS will probably
>> page it out because we don't touch it. This is assuming quite a bit
>> though.
>>
>> At no point did I
On Tue, 2011-12-06 at 17:20 +, Luke Daley wrote:
> It's your imagination Russel, go back to sleep :P
Or moan about something else that's broken. Moaning about broken things
seems to get them fixed!
--
Russel.
=
Dr R
On Tue, 2011-12-06 at 10:11 -0700, Daz DeBoer wrote:
[...]
> > Looks like this has been fixed in master:
> https://github.com/gradle/gradle/commit/2b42950f49ff6559b95adb0231c53b8cb55e4c3a.
> Fix should be in Milestone 7, on it's way very soon.
I built HEAD yesterday (actually a more or less daily
Luke Daley-2 wrote
>
> The issue at hand is how to think about default settings for memory usage,
> particularly heap. If we are going to provide defaults, we'll have to
> either be conservative to avoid the JVM using too much memory or be more
> generous to allow the defaults to be more useful f
