ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: flexible cache management (IVY-399)
Date Thu, 03 Jan 2008 17:00:28 GMT
On Jan 3, 2008 3:52 PM, Nascif Abousalh-Neto <>

> Hi Xavier,
> I think that you should use "lockStrategy" in both places, it is more
> effective in denoting the attribute meaning. It definetely should be the
> same name if it is configuring the same thing!

I used 'lock' in cache instance to mimic the latest attribute which
configures the latest strategy of a resolver. But I agree both should use
the same name, and lockStrategy is more effective. Do anybody else has an
opinion for that?

> I also think that it is reasonable to break backward compatibility given
> that you are introducing new and richer functionality that can't be easily
> made to conform to the previous API. But if you can support both ways and
> provide a "deprecated" warning for the old one, even better.

To make things clear it's breaking backward compatibility only with a beta
feature, not with a release feature. I should have marked the cache
management introduced in beta 1 experimental to make it clear it was a work
in progress, at least in terms of configuration. So we could preserve
backward compatibility with the beta with deprecation but I think it's not
worth the trouble of documenting twice very similar stuff only for people
who use this feature in beta 1. If migrating to beta 2 is easy enough, it
should be ok for the users IMO. Does it make sense?


> My US$0.02,
>  Nascif
> -----Original Message-----
> From: Xavier Hanin []
> Sent: Thursday, January 03, 2008 7:59 AM
> To: Ant Developers List
> Subject: flexible cache management (IVY-399)
> Hi,
> Last week I've worked on the cache management to improve its flexibility.
> Now the two kind of caches (resolution and repository caches) are
> available,
> and the repository cache is now much more flexible: new implementation can
> be supplied by users, and one can choose which repository cache instance
> to
> use for each resolver.
> By default only one repository cache instance is created, configured using
> defaults value which can be overridden. To ease the settings, any cache
> instance created by the user and relying the default repository cache
> implementation will use the same defaults, so that one can easily override
> the pattern used by all the cache instances used.
> An example of how this can be configured in the current trunk is available
> here:
> The <cacheDefaults> element configures default values for both the
> repository and resolution cache:
> <cacheDefaults
>   resolutionDir="resolution"
>   repositoryDir="repository"
>   repositoryIvyPattern="[module]/ivys/ivy-[revision].xml"
>   repositoryArtifactPattern="[module]/[type]s/[artifact]-[revision].[ext]"
>   lockStrategy="artifact-lock"
> />
> Note that unlike 2.0 beta 1, resolutionDir and repositoryDir are not
> relative to a common cache basedir, but are absolute paths. A default
> basedir can still be configured in cacheDefaults using defaultBasedir
> attribute, which is used as default value for both resolutionDir and
> repositoryDir if none is provided.
> Then repository cache instances are configured in the <caches> element:
> <caches>
>  <cache name="mycache"
>     basedir="mycache"
>     ivyPattern="[module]/ivy-[revision].xml"
>     artifactPattern="[module]/[artifact]-[revision].[ext]"
>     lock="no-lock"
>   />
>   <cache name="mycache2" />
> </caches>
> Here the cache named 'mycache' is configured extensively (no use of the
> defaults) while the cache 'mycache2' is only defining one new cache
> instance, using only default values for its base directory, patterns and
> lock strategy.
> Then one can define the repository cache instance to use in one resolver
> by
> setting the cache attribute:
> <filesystem name="B" cache="mycache">
>  <ivy pattern="${libraries.dir
> }/[organisation]/[module]/ivys/ivy-[revision].xml"/>
>  <artifact pattern="${libraries.dir
> }/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
> </filesystem>
> I'd like to gather some feedback about these changes:
> - Are attribute and element names well chosen? There is for example an
> inconsistency between lockStrategy on cacheDefaults and lock on a cache
> instance. I guess we should better be consistent, which one do you prefer?
> Is the use of cacheDefaults as element name good or should we use cache as
> introduced in 2.0 beta 1?
> - Is breaking the compatibility with 2.0 beta 1 a problem? In beta1 cache
> defaults were provided in a cache element, where resolution and repository
> basedir were relative to a common basedir.
> - Is the defaultBasedir attribute on cacheDefaults a good idea? It's
> basically provided as an equivalent to defaultCache attribute on the
> settings element, itself provided for backward compatibility reason. But
> I'm
> wondering if we shouldn't deprecate the defaultCache attribute on the
> settings element, and remove defaultBasedir on cacheDefaults, so that user
> configure both resolutionDir and repositoryDir explicitly to make people
> always aware of the two kind of caches.
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

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