I'm updating the <caches> element of the ivy-settings, but am
encountering what looks to be a strange bug.
If I set:
<caches
repositoryCacheDir="${ivy.default.ivy.user.dir}/repositoryCache"
resolutionCacheDir="${project.home}/.ivy2/resolutionCache"
lockStrategy="artifact-lock"
useOrigin="true"/>
Then it appears that the repositoryCacheDir is ignored, however, if I set:
<caches defaultCacheDir="${ivy.default.ivy.user.dir}/defaultCache"
repositoryCacheDir="${ivy.default.ivy.user.dir}/repositoryCache"
resolutionCacheDir="${project.home}/.ivy2/resolutionCache"
lockStrategy="artifact-lock"
useOrigin="true"/>
then it appears that the repositoryCacheDir is correctly used (and the
defaultCacheDir is properly ignored).
Sam
2009/3/19 Sam Berlin <[email protected]>:
> Yes, I have noticed significant problems when using ivy in a parallel
> build environment (essentially, any build-server), and we've only had
> Ivy in use on the buildserver for ~12 hours. The only solution I can
> think of is to make the cache local per build, which is pretty far
> from ideal.
>
> Any suggestions for how to make Ivy more robust against concurrent builds?
>
> Sam
>
> 2009/3/19 Uldis Karlovs-Karlovskis <[email protected]>:
>> And this is not all. Previous case was when artifact is already in cache. If
>> Ivy needs to download new artifact then parallel execution gives something
>> like this:
>>
>> ---------------------------------------------------------------------
>> | | modules || artifacts |
>> | conf | number| search|dwnlded|evicted|| number|dwnlded|
>>
>> ---------------------------------------------------------------------
>> | default | 4 | 0 | 0 | 0 || 6 | 0 |
>>
>> ---------------------------------------------------------------------
>>
>> :: problems summary ::
>> :::: WARNINGS
>> problem while downloading module descriptor:
>> http://server/download?name=somemodule&version=1.3.1.16&file=somemodule&file
>> Type=xml: impossible to move part file to definitive one:
>> /root/.ivy2/cache/ctco/somemodule/ivy-1.3.1.16.xml.original.part ->
>> /root/.ivy2/cache/ctco/somemodule/ivy-1.3.1.16.xml.original (21ms)
>>
>> module not found: ctco#somemodule;1.3.1.16
>>
>> ==== bones-repository: tried
>>
>>
>> http://server/download?name=somemodule&version=1.3.1.16&file=somemodule&file
>> Type=xml
>>
>> ::::::::::::::::::::::::::::::::::::::::::::::
>>
>> :: UNRESOLVED DEPENDENCIES ::
>>
>> ::::::::::::::::::::::::::::::::::::::::::::::
>>
>> :: ctco#somemodule;1.3.1.16: not found
>>
>> ::::::::::::::::::::::::::::::::::::::::::::::
>>
>>
>>
>> :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>> command exit code: 1
>>
>> Regards,
>> Uldis, C. T. Co
>> [email protected]
>>
>>
>> -----Original Message-----
>> From: Uldis Karlovs-Karlovskis [mailto:[email protected]]
>> Sent: ceturtdiena, 2009. gada 19. martā 17:37
>> To: [email protected]
>> Subject: Running Ivy in parallel builds
>>
>> Hello!
>>
>>
>>
>> Have You tested running Ivy in more than one build at the time?
>>
>> I see there are few files in cache which got updated every time I run Ivy.
>> When my build system is running more than one process at the time sometimes
>> I got this exception:
>>
>> :: retrieving :: lv.ctco#scm-bootstrap
>>
>> confs: [default]
>>
>> Caught: java.lang.RuntimeException: problem during retrieve of
>> <namespace>#<module>: java.text.ParseException: failed to parse report:
>> /root/.ivy2/cache/lv.ctco-scm-bootstrap-default.xml: Premature end of file.
>>
>> command exit code: 1
>>
>>
>>
>>
>>
>> Uldis Karlovs - Karlovskis
>>
>> Lead SCM Engineer
>>
>> System Configuration Management
>>
>> C.T.Co
>>
>> Mobile: +371 29 345 210
>>
>>
>>
>>
>>
>
