Not sure of this, but it's worth a shot. I'm presuming that you did one ivy:resolve with the one Ivy settings and another ivy:resolve with the other Ivy settings. Try giving both these resolves their own unique resolveId attribute value. Then specify the respective resolveId attribute values in the corresponding ivy:cachefileset and ivy:cachepath tasks. When Ivy is trying to get the resolve data for use with a post-resolve task, I don't know if it purposely ignores the last resolve if that resolve was done against a different Ivy settings.
On Sat, Aug 14, 2010 at 6:34 AM, Blaine Simpson <blaine.simp...@admc.com>wrote: > 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. >
