Didn't we already get a jira issue from the original poster of the problem?
> -----Original Message----- > From: Gilles Scokart [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2008 3:32 AM > To: [EMAIL PROTECTED] > Subject: Re: Error message when using different settings > > On 05/03/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > On Wed, Mar 5, 2008 at 3:35 PM, Jim Adams <[EMAIL PROTECTED]> wrote: > > > > > Since the cache is global to all processes running on the machine I > > would > > > think that it is very possible to get in the described situation. I > > could be > > > downloading the same named module using 2 different resolvers and the > > > modules could serve very different purposes. I may be forced into this > > for > > > legacy reasons. I think the solution would be that the resolve engine > > take > > > into account the resolver that was used to resolve the module and ignore > > any > > > module resolved by a different resolver. > > > > > > Mm, I see different cases, with different answers. In some cases you use > > the > > same cache with different settings and even different repositories with > > different metadata (this happens when you work on different projects, each > > with its own settings, but using the default cache location). Then you'd > > like Ivy to be able to isolate work from each dependency resolution, to > > avoid strange collisions. The other use case is Hans' one, where you have > > different settings but all of them lead to the same repositories, so you > > want to really share the cache to improve performance. > > > > I think Ivy should support both, with sensible defaults. > > > > > > > Yes, ivy should support both, and I think that should be configurable at the > level of the cache. We could either have a parameter indicating if the > cache should be "resolver aware" (I think that would be difficult to > implement) or have the cache being always "resolver unaware" and ask to the > user to use 2 separated cache if he want the isolation between 2 repository > accross build (might be easier to implement). > > Can someone raise a jira issue for that? > > -- > Gilles Scokart
