On Oct 29, 2009, at 9:17 PM, Adam Murdoch wrote:
Hans Dockter wrote:
On Oct 29, 2009, at 8:35 PM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi Steven,
we have some issues with our incremental build in trunk. Try to
rebuild with: -C rebuild
Some of the cache state is in <userGradleHome>.
I don't think it's the incremental build stuff.
Sorry. I shouldn't answer this kind of email from my mobile phone
without reading the stacktrace properly.
Those are ivy warnings in the output, and the path it's trying to
write to looks like the internal repository has come back for some
reason.
In this form it was always there. Ivy is always writing the
deployment descriptors into the cache.
There's some way to stop it caching anything on the file system for
the internal repository. I managed to do so a while back, but I
can't remember how. For some reason, ivy is using the cache again.
I'm not sure. Ivy usually always use the cache for the ivy.xml's
relevant for resolving a configuration, as it always writes an xml
file with the data of a resolve for a configuration.
Perhaps the recent refactoring in there switched it back on?
I can't see how any of my changes could have affected this behavior (I
know, that is what they always say ;)).
The problem is that I have changed the name of the project
dependency to its path when resolving. Therefore we have this
issue. I will transform colons into underscores for the name and
everything should work fine then on windows.
I think a better solution is to not cache anything (for the internal
repository, that is)
As I understand the ivy logic this is not possible, as the reason why
ivy writes the ivy.xml's of the resolved dependency into the cache is
not resolver specific.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
