On Jan 4, 2008 4:46 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > I have the feeling the checkModified, the changingPattern and the > changingMatcher are more a property of the remote > repository (the way the repository is build) than a property of the local > cache (the way one particular user want to > cache the files). > > WDYT?
I see your point, but if you think about what these properties do, they only tell Ivy when to trust the cache or not. I agree this is closely related to a repository, but since you can use a cache per resolver you can still do whatever you want with these settings in cache instances rather than resolver. What's interesting is that you can share a cache instances among resolvers, so you can use the same cache behavior for several resolvers (think all your remote repositories for example). If we push cache features further (like adding a TTL to dynamic revision resolution), the TTL would make sense in the cache settings and would be very closely related to checkModified / changingPattern / ... Does it make sense? Xavier > > > Gilles > > > -----Original Message----- > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > Sent: vendredi 4 janvier 2008 16:25 > > To: dev@ant.apache.org > > Subject: Consolidate cache related settings > > > > On Dec 28, 2007 1:29 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > > One thing I'd still like to change in this area besides the fix and > > > improvement in flexibility is to make repository cache managers > responsible > > > for managing the useOrigin flag. It would be much more consistent IMO, > and > > > also more flexible, allowing to use one cache manager for one resolver > with > > > useOrigin=true, and another cache manager for another resolver with > > > useOrigin=false. > > > > > > This would mean removing useOrigin flag from the tasks, and adding it > to > > > the cache settings (which will have to be improved to allow per > resolver > > > cache manager). Since this would be a task backward incompatibility > (which > > > we tend to avoid to ease 2.0 migration), I'd actually keep the > useOrigin > > > attribute on the related tasks, but deprecate it, and only set a > property > > > from the value set on the attribute. Then this property would be used > as > > > default value for the useOrigin flag on the default repository cache > manager > > > (used by all resolvers unless they specify another repository cache > > > manager). > > > > > > After more work on the cache management, I see other settings which > > currently belongs to dependency resolvers and would better go in cache > > manager IMO: > > - check modified > > - changing pattern and changing matcher > > > > Indeed these settings are used to know if a module metadata or artifacts > can > > change, and this is useful only for caching purpose. So instead of > putting > > these settings on the resolvers, I think moving them to cache manager > would > > be more consistent. As for the useOrigin, we should still try to be > backward > > compatible. We could say that the default values for check modified and > > changing patterns and matchers in a cache manager may depend on the > context > > in which they are being used (in other words let the dependency resolver > > override the default when calling the cache manager). > > > > Any objection? > > > > Xavier > > > > -- > > Xavier Hanin - Independent Java Consultant > > http://xhab.blogspot.com/ > > http://ant.apache.org/ivy/ > > http://www.xoocode.org/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
