1

I'm using Hudson with Ant+ivy and many jobs which starts in parallel. My problem is that I use a cache folder for Ivy which is deleted and updated in the ant task of every job.

Of course, several builds fail because they can't delete the ivy folder and some other fail because the can't find the libraries being deleted at the same time.

BUILD FAILED

C:\dev.hudson\jobs\api\workspace\build\build.xml:100: Unable to delete the directory C:\dev\tools\build\ant\extensions\ivy\cache\myapp

and

BUILD FAILED

C:\dev.hudson\jobs\api\workspace\build\build.xml:104: impossible to resolve dependencies: resolve failed - see output for details

Anders Lindahl
  • 41,582
  • 9
  • 89
  • 93
enjoy
  • 21
  • 4
  • http://stackoverflow.com/questions/1293113/how-to-override-the-location-of-ivys-cache – Anders Lindahl May 03 '12 at 09:23
  • Use the answer provided by Anders to setup a cache unique to each project. In this way each build is isolated from each other. See a related question (Maven and Jenkins, but same principle) http://stackoverflow.com/questions/7582271/prevent-jenkins-from-installing-artifact-to-local-maven-repository/7587606#7587606 – Mark O'Connor May 03 '12 at 18:59

1 Answers1

0

If you really need to purge your cache everytime Anders answer is the way to go.

I would prefer to keep a cache for all external libraries (or libs that won't change that much) and a project-based cache that gets purged all the time.

For the rarely changing cache a lock-strategy will be useful, to handle multi-threaded access.

A lock strategy should help here. If you only use ivy commands to handle the cache, this will make sure that only one process is "active in it".

You can enable it in your ivysettings.xml generally.

<lock-strategies><artifact-lock/></lock-strategies>

Or on cache level.

oers
  • 18,436
  • 13
  • 66
  • 75
  • If each build is purging the cache, it would make more sense to setup a cache for each project – Mark O'Connor May 03 '12 at 18:55
  • @MarkO'Connor you are right. If purging is really needed this would be best. – oers May 04 '12 at 05:23
  • And what happen if my libraries in cache have changed (they havec the same name, version,...) but not the same size anymore. Does Ivy knows that and loads the new libraries? – enjoy May 04 '12 at 11:47
  • @enjoy you can set checkmodified and changingPattern to any [resolver](https://ant.apache.org/ivy/history/latest-milestone/settings/resolvers.html). – oers May 04 '12 at 12:29
  • @enjoy I also used the [latest-time](https://ant.apache.org/ivy/history/2.2.0/settings/latest-strategies.html) strategy on resolvers for changing artifacts. I think that this worked best for me. – oers May 04 '12 at 12:35
  • So, do you think that using both useOrigin="true" and checkModified="true" could be the good strategy? – enjoy May 07 '12 at 06:22
  • @enjoy I use this strategy for my build artifacts and it worked for me (I also used to clean the cache before building, but I wanted to get rid of downloading all the external artifacts every time). But I don't remember if useOrign works well in a multi threaded environment. I deploy my artifacts with a filesystem resolver to a special directory and use the latest time strategy on this resolver. – oers May 07 '12 at 06:46
  • thank you.Unfortunately,I've now another exception: [ivy:retrieve] :: retrieving :: myproject#api [ivy:retrieve] confs:[compiletime] BUILD FAILED C:\dev\.hudson\jobs\api\workspace\build\build.xml:118: impossible to ivy retrieve: java.lang.RuntimeException: problem during retrieve of myproject#api: java.text.ParseException: failed to parse report: C:\dev\tools\build_trunk\ant\extensions\ivy\cache\my-project-compiletime.xml: Content is not allowed in trailing section. ->Is it because several threads try to read/write the same file? Are locks possible here?ps:should i write a new post for this? – enjoy May 07 '12 at 07:28
  • @enjoy the xml file seems to be illegal, don't know how this could happen. – oers May 07 '12 at 07:31
  • @oers this is online when several jobs using the same project are started at the same time. Could it be that one of those jobs rewrites the xml file while others (e.g. the one creating this parseexception) try to read it? – enjoy May 07 '12 at 07:38
  • @enjoy If you use a locking strategy then this shouldn't happen. Otherwise it could. – oers May 07 '12 at 07:39