ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Verstraeten <>
Subject Re: Ivy + hudson CI - problems downloading artifacts, please, help
Date Wed, 24 Feb 2010 17:09:32 GMT

The problem is due to concurrent access to the Ivy cache. I was unable 
to get that working, so I simply configured each Hudson job to have its 
own cache directory.

I did that by adding following line to the settings file used by the 
Hudson job :

<caches defaultCacheDir="${basedir}/ivycache" useOrigin="true"/>

This assumes that you invoke Ivy through the ant tasks, in which case 
the ${basedir} attribute is expanded to the ant build's basedir.

Hope this helps,
Willem wrote:
> Hi,
> I'm not subscribed to the list, so, please, make sure you have my 
> address in CC for replies.
> We are having more than 150 projects in hudson CI with dependencies 
> tracked by Ivy (2.1.0).
> Lately we are having more and more problems with it because ivy cannot 
> copy/download artifacts correctly.
> There are two main errors we are getting:
> 1. size of source file differs from the size of dest file
> 2. impossible to move part file to definitive one
> In mailing list i found this answer from Xavier Hanin:
> When Ivy downloads ivy files from a repository, it first download them 
> to a
> temporary file (used to be in temp directory until 2.0 beta 1, where 
> the ivy
> file is downloaded to the cache). Then it moves the temporary file to the
> final location in the cache, and this is what seems to be failing for 
> your
> user. Cleaning the cache should fix the problem, if it happens frequently
> you should try to investigate the issue. Maybe it is due to the use of 
> the
> same cache by multiple processes concurrently. This use case is supported
> only with 2.0 beta 1, with the repository cache locking to avoid such
> concurrency issues.
> As i mentioned above our version is 2.1.0, but we still have this issue
> I also saw the same problem reported before, but there was no answer
> Thanks,
> Eugene

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message