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
