ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Consolidate cache related settings
Date Sat, 05 Jan 2008 00:52:23 GMT
On Jan 4, 2008 4:46 PM, Gilles Scokart <gscokart@gmail.com> 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:xavier.hanin@gmail.com]
> > 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 <xavier.hanin@gmail.com> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message