Let me take a stab at addressing your immediate problem, even though I don't have a direct answer. But then I'm going to suggest a different approach that avoids that problem.
Frankly, I've never used configure, only settings. The configure documentation explains the primary difference (basically settings is lazy): http://ant.apache.org/ivy/history/latest-milestone/use/configure.html As you describe, the immediate problem is that, with settings, the EXECUTOR_NUMBER environment variable is not being picked up. The following line is really just establishing a default: <property name="env.EXECUTOR_NUMBER" value="0" override="false"/> For debugging's sake, I'd try leaving that out. The executor number should be required. For debugging's sake, I'd also try outputting the value in the Ant build just prior to calling ivy:settings. Also, I'd make sure that ivy:settings is always getting called before ivy:cleancache. And there's something I find odd about your caches specification: <caches defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}" resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/> It appears that your resolution cache is not being defined on a per-executor basis. If each executor build has its own target directory, that's OK. But then, why not do that for both your resolution cache and your repository cache? So you'd specify resolutionCacheDir and repositoryCacheDir attributes (no defaultCacheDir) in a consistent way. I forget if Jenkins checks out the source into a different location for each executor build (it should), but if that's the case and you're sending your output to a location relative to your source, then establishing a relative path to your caches should suffice, and there's no need to establish cache-${env.EXECUTOR_NUMBER} directories. And in fact, now that I think of it, specifying Ivy caches for a CI build that are based on ivy.default.ivy.user.dir, considering that its default is user.home/.ivy2/, is a bit of an antipattern. On Thu, Nov 29, 2012 at 8:35 AM, David Weintraub <qazw...@gmail.com> wrote: > When is it better to use <ivy:settings> vs. <ivy:configure>? > > I ask because I was having a problem with my Ivy setup. We use Subversion > and have multiple projects setup that use Ant. In order to centralize our > jar dependencies, I've decided to implement Ivy into our process. > > I did this by creating an Ivy project (https://github.com/qazwart/ivy.dir) > in Subversion. Users merely set `svn:externals` to include this project, > make some minor changes in their build.xml, and add in a "ivy.xml" file, > and everything is set. I control the ivysettings.xml file, so I point Ivy > to our repository. The Ivy jar is part of the Ivy project, so users don't > have to install it. The idea was to make Ivy integration as painless as > possible. > > We use Jenkins as our build system, and I decided it would be good if we > could clean the Ivy cache before each build. However, out Jenkins system > has six executors, so as many as six builds could happen at once. Cleaning > the cache in one build while another one runs could cause problems, so I > modified my ivysettings.xml file to use a different cache depending upon > the executor: > > <ivysettings> > <property name="env.EXECUTOR_NUMBER" value="0" override="false"/> > <caches > > defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}" > resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/> > <settings defaultResolver="default"/> > <include file="${ivy.dir}/ivysettings-public.xml"/> > <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/> > <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/> > <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/> > <include > url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/> > </ivysettings> > > The problem is that if I did an <ivy:cleancache>, the cache ID was always > set to "cache-0". When I switched from "<ivy:settings>" to > "<ivy:configure>", the problem went away. (In the standard build process, > the <ivy:cleancache> task is executed before the <ivy:resolve> task). > > I'm told that "<ivy:settings>" can do multiple configurations, but it looks > like <ivy:configure> also can do multiple settings too. I also read that > "<ivy:configure>" was deprecated in some mailings, but it doesn't state > that in the on line documentation. > > So what is the difference between <ivy:settings> and <ivy:configure>, and > when should I use one over the other? > > -- > David Weintraub > qazw...@gmail.com >
