Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Fri, 13 Mar 2009 00:03:49 +0100
From: Daniel Dekany <ddekany@freemail.hu>
Reply-To: Daniel Dekany <ddekany@freemail.hu>
Message-ID: <858231224.20090313000349@freemail.hu>
To: "Brown, Carlton" <ivy-user@ant.apache.org>
Subject: Re: [solved] How to prevent "unknown resolver" errors?
In-Reply-To: 
 <EE7473F9E5EC3D4CBC1CDDD38BC1FA320A250454@CWA0020EX.ccsouth.cccore.com>
References: <708997897.20090309174709@freemail.hu>
 <EE7473F9E5EC3D4CBC1CDDD38BC1FA320A24FC51@CWA0020EX.ccsouth.cccore.com>
 <813352657.20090311171844@freemail.hu>
 <EE7473F9E5EC3D4CBC1CDDD38BC1FA320A24FCF5@CWA0020EX.ccsouth.cccore.com>
 <1236574665.20090311192242@freemail.hu>
 <1668916073.20090311225834@freemail.hu>
 <EE7473F9E5EC3D4CBC1CDDD38BC1FA320A2501B0@CWA0020EX.ccsouth.cccore.com>
 <133053133.20090312154020@freemail.hu>
 <EE7473F9E5EC3D4CBC1CDDD38BC1FA320A250454@CWA0020EX.ccsouth.cccore.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit

Thursday, March 12, 2009, 6:33:27 PM, Brown, Carlton wrote:

>> -----Original Message-----
>> From: Daniel Dekany [mailto:ddekany@freemail.hu] 
>> Sent: Thursday, March 12, 2009 10:40 AM
>> To: Brown, Carlton
>> Subject: Re: [solved] How to prevent "unknown resolver" errors?
>> 
> [snip]
>> >> 
>> >> To answer my above question... I now tried using separate
>> >> *resolution* caches for each ivysetting.xml-s, but with the common 
>> >> per-user
>> >> *repository* cache, ${user.home}/.ivy2/cache.  As the 
>> >> ivysetting.xml-specific resolver names still get into 
>> >> ${user.home}/.ivy2/cache (yes, into the *repository* cache part of 
>> >> it), it can still cause "undefined resolver" errors in *other* 
>> >> projects that use ${user.home}/.ivy2/cache too. It doesn't cause 
>> >> errors in my project though, as it knows the custom resolvers.
>> >
>> > If you're getting this behavior, think you've either made 
>> an error in
>> > configuration or uncovered a bug.   Could you post your respective
>> > config files rather than describing what you did?  
>> 
>> I would believe that the authors are aware of this. Simply, 
>> the name of the last resolver of an artifact is stored in the 
>> ivydata-[revision].properties file as the "resolver" 
>> property. And that file belongs to the repository cache, not 
>> to the resolution cache, right?
>
> Correct, it was my mistake. The repository cache does contain
> resolver information (at least as of 2.0.0). I think the design is
> sound... The cache should contain some resolver state, otherwise it
> couldn't work offline and still respect the resolvers that Ivy does
> know about.

(In my experience it can't work safely off-line anyway... unless you
create a local mirror repository, of course.)

> But I think the "unknown resolver" error is a bug... in
> my opinion Ivy shouldn't error out if it encounters an unknown
> resolver, as long as the resolver doesn't get used. You can go here
> and open a bug and see if the developers agree:
> https://issues.apache.org/jira/browse/IVY

Ugh... I'm shy about reporting this particular one. I already filled a
few reports, where I'm quite confident Ivy behaves badly. But this...
I at best have blurry ideas regarding how that information is supposed
to be used. I rather filled a documentation improvement request
regarding cache setup and multiple ivysettings.xml-s...

> [snip]
>> Simply, since multiple projects use the same ivysettings.xml, 
>> and they may be built in parallel (think about a continuos 
>> integration server), and the resolution caches shouldn't be 
>> accessed concurrently (according to the Ivy docs), I think I 
>> can't use just one resolution cache per ivysettings.xml. Can 
>> I?
>
> You can specify the default cache as a property and then override it
> from the build script before you call ivy:settings.

Yes, for example. Hence you have one resolution cache per project,
rather than one per ivysettings.xml.

-- 
Best regards,
 Daniel Dekany