ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nascif Abousalh-Neto <Nascif.AbousalhN...@sas.com>
Subject RE: flexible cache management (IVY-399)
Date Thu, 03 Jan 2008 14:52:44 GMT
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 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.

My US$0.02,
  Nascif

-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
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:
https://svn.apache.org/repos/asf/ant/ivy/core/trunk/test/java/org/apache/ivy/core/settings/ivysettings-cache.xml

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.

WDYT?

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