On Fri, Apr 06, 2007 at 08:42:27AM +0200, Xavier Hanin wrote: > On 4/6/07, Jing Xue <[EMAIL PROTECTED]> wrote: > >BTW, on a side point unrelated to the topic of this message, please note > >that in the above scenario, I also _do_ have the log4j 1.2.14 in my > >local ivy cache, yet it went ahead and checked ibiblioResolver... > > > This is really strange. I haven't tested with a cache resolver (it's not > very often used, since Ivy itself relies on its cache as often as possible > without any specific settings), but it's unit tested in general case, and > I've checked the code and I don't see why if the first resolver returns > something the chain could continue (with returnFirst=true). But if you want > to help us investigate, could you please send a debug log, adn we'll see if > we better understand what's happening.
Hi Xaviar, Please see the following debug output: [ivy:resolve] using main to resolve [ org.apache.ant | ant-junit | 1.7.0 ] [ivy:resolve] pre 1.3 ivy file: using exactOrRegexp as default matcher [ivy:resolve] found ivy file in cache for [ org.apache.ant | ant-junit | 1.7.0 ] (resolved by ibiblioResolver): /home/jingxue/.ivy/cache/org.apache.ant/ant-junit/ivy-1.7.0.xml [ivy:resolve] cacheResolver: revision in cache: [ org.apache.ant | ant-junit | 1.7.0 ] [ivy:resolve] found [ org.apache.ant | ant-junit | 1.7.0 ] in ibiblioResolver I think the cache resolver did successfully resolve it, but somehow prints the wrong resolver name on the last name. As for the log4j case in my previous message, I realized that ivy was actually going to ibiblio because the cache resolver isn't capable of resolving non-exact versions. Thanks. -- Jing Xue
