>Also, could you raise a jira issue for this? http://issues.gradle.org/browse/GRADLE-1723
Cheers! On Thu, Aug 4, 2011 at 1:20 AM, Adam Murdoch <[email protected]>wrote: > > On 04/08/2011, at 9:15 AM, Rene Groeschke wrote: > > Hi, > > thanks for sharing your experiences. I've noticed some changes in the > resolving behavior in the griffon build as well. there seems to be a > different conflict strategy as well? > > Am 03.08.2011 um 19:55 schrieb Daz DeBoer <[email protected]>: > > One thing to be aware of: as of M4 caches are now isolated per repository, > meaning that you only ever have access to the cached artifacts for the > declared repositories. In previous versions a single shared cache was used, > similar to how Maven works. So previously you could fail to declare a > required repository, but the artifacts could still be resolved as > dependencies if they were in the cache. > > > On upgrade to M4, I experienced dependency resolution problems in one of my > test build scripts: turns out that I was just relying on the slf4j and > groovy dependencies being in the cache (which they were) and I was not > declaring the repository required to find them. Upgrading to M4 forced me to > add the required repository. > > > Not sure if this is related to your problem (the "impossible to acquire > lock" looks suspicious), but it's worth knowing when tracking down > dependency resolution problems using M4. > > > since we use dedicated cache locations for our builds on the ci-server, > this does not be the problem. i'll try to drill down the problem to a > reproducable example as soon as i find time in the office. > > > With the build not running, see if you have any .lck files anywhere under > $homeDir/caches/artifacts. You should delete these - if they are present Ivy > will complain that it cannot acquire the lock. It looks like ivy/wharf is > not always cleaning these up when the build process exits. > > Also, could you raise a jira issue for this? > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
