ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Trump" <>
Subject On-server ivy settings?
Date Fri, 04 Jan 2008 21:15:42 GMT
New feature suggestion (obviously not for 2.0):  allow some kind of optional ivy settings file
on the ivy repository.  This would allow for less configuration on the ivy client side, and
make it easier to update the structure of your ivy repository.  Things that could go in this
* artifact and ivy patterns for the repository
* repository-sensitive cache hints like changingPattern and changingMatcher
* pointers to other repositories where artifacts are stored (so that client doesn't have to
know about these)
* lists of mirror or backup servers to improve availability
though maybe the last one is better handled in custom repository implementations.  The client
config would then look something like:
        <url settings="/server/path/to/ivysettings.xml"/>
I know that you can do similar things with a remote ivysettings.xml file, but I liked the
idea of putting information about the ivy repository in the repository itself.  What do you
think?  Is it worth mentioning in a JIRA issue?

From: Xavier Hanin []
Sent: Fri 1/4/2008 7:24 AM
Subject: Consolidate cache related settings

On Dec 28, 2007 1:29 AM, Xavier Hanin <> 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 Hanin - Independent Java Consultant

View raw message