I am using two independent ivy settings instances from Ant:
<ivy:cachefileset settingsRef="ivy.js.settings" conf="default"
file="ivy-js.xml" setid="js.ivyrefid"/>
<ivy:cachepath conf="build" settingsRef="ivy.jar.settings"
file="ivy-jar.xml" pathid="build.ivyrefid"/>
Either of these alone work just fine. When I run both, in either order, the
second fails with a message like:
impossible to build ivy path: bad confs provided: build not found among
[default]
The thing is, the very last word there is wrong: "... found among [default]".
The big ASCII art box listing the dependency counts immediately above shows that
Ivy has successfully found 8 modules for the "build" conf (default conf is only
used in ivy.js.xml). I'll spend a few more bytes to show this:
[ivy:cachepath] :: resolution report :: resolve 303ms :: artifacts dl 24ms
---------------------------------------------------------------------
| | modules || artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
---------------------------------------------------------------------
| build | 8 | 0 | 0 | 0 || 8 | 0 |
---------------------------------------------------------------------
BUILD FAILED
/home/blaine/autotable-0.2b3/build.xml:128: impossible to build ivy path: bad
confs provided: build not found among [default]
It seems to me that the resolution has succeeded 100% but then some very late
action of the ivy:cachepath goes outside of its assigned ivy.jar.settings and
looks into ivy.js.settings. The situation is exactly inverted, as this
hypothesis would predict, if I reverse the order of the two tasks.
I get the same exact behavior with both Ivy 2.1.0 and 2.2.0-rc1. My current
work-around is to never invoke Ant so as to run both of these commands in a
single Ant invocation. Instructing team members about this work-around is
causing me political headaches, as I'm the primary Ivy advocate at my company.
