We keep our resolver chains in separate file and then configure which to use
via ant properties:
we have a target that sets a property
<target name="with.geonet.enterprise.only" description="Tells ivy to use
the enterprise repositories settings only.">
<property name="geonet.ivy.settings"
value="ivysettings-geonet-enterprise-only.xml"/>
</target>
This is followed by a default and a load of the ivy settings.
<!--Ant properties are immutable, so this only takes effect if it hasn't
been set in some previous target.-->
<property name="geonet.ivy.settings"
value="ivysettings.xml"/>
<ivy:settings id="ivy.geonet"
url="
http://repo.geonet.org.nz/ivy/repo/${geonet.ivy.settings}">
<credentials host="repo.geonet.org.nz"
realm="GeoNet" username="repo" passwd="maven"/>
</ivy:settings>
Then we can use the property to hit just our enterprise repo or allow the
default which includes everything
ant with.geonet.enterprise.only ivy-resolve
or
ant ivy-resolve
Cheers,
Geoff
On Wed, May 12, 2010 at 7:33 AM, Valerie Wagner <[email protected]>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
>
>