ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: <ivy:configure> vs. <ivy:settings>
Date Thu, 29 Nov 2012 17:32:32 GMT
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):

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

And there's something I find odd about your caches specification:

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 <> 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 (
> 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

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