ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Trump" <Jason.Tr...@mantis-tgi.com>
Subject RE: Consolidate cache related settings
Date Fri, 04 Jan 2008 20:48:22 GMT
Seems like checkModified / changingPattern / changingMatcher all change local cache behavior
in response to a particular remote repository.  So the structure comes from the rep, but the
behavior is all about the cache.  I think it might be clearer what these properties do if
they are moved to cache settings as Xavier suggests.
 
PS. i'm really excited about the new cache features.  a lot of the things we are doing with
multi-project builds at my company will be a lot easier now.

________________________________

From: Gilles Scokart [mailto:gscokart@gmail.com]
Sent: Fri 1/4/2008 7:46 AM
To: 'Ant Developers List'
Subject: RE: Consolidate cache related settings



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?

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





Mime
View raw message