ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: Can I dynamically change the "defaultResolver"?
Date Tue, 11 May 2010 20:02:02 GMT
Valerie, the solution I like for this problem uses the include and property
elements of the Ivy settings schema, and actually it's not far off from what
you describe, despite your misgivings. So you might specify in your
  <settings defaultResolver="default-resolve-resolver" />
  <property name="ivy.settings.environment"
            override="false" />
  <include file="ivysettings-${ivy.settings.environment}.xml" />

So by default, you include the Ivy settings for your server configuration,
ivysettings-server.xml, which contains one definition of
default-resolve-resolver. But because the ivy.settings.environment property
can be overridden by the consumer of the Ivy settings, you could selectively
load ivysettings-local.xml, with its own definition of

On Tue, May 11, 2010 at 12:33 PM, Valerie Wagner <>wrote:

> It seems to me it should be simple to change what the "defaultResolver" is
> (as defined in the ivy setting files <settings> element), but I cannot find
> documentation on this.
> We use a resolver chain that hits the local file system and a remote Ivy
> server. However, we occasionally build in restricted environments with no
> internet access, in which case we do not want the build system attempting to
> contact the Ivy server (as it causes the build to fail).
> I've separated our resolves into "local" and "server" chains, with the
> default chain using both. However, I need my team to be able to specify that
> they use only the "local" resolver chain on occasion. (Assuming they have
> all the necessary libs from the server in their cache already.)
> I think I could accomplish this by putting the local and server chains in
> separate ivy settings file, and switching which one is loaded at runtime,
> but this seems like a very roundabout way to do it. After all, the term
> "default" resolver implies to me there should also be a way to use an
> alternative, non-default resolver chain.
> thanks,
> Valerie

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