On Jan 3, 2008 3:29 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > Sent: jeudi 3 janvier 2008 13:59 > > 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/ivysetti > > ngs-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 > > I'm actually wondering if we should keep the <cacheDefaults>. > > I mean, all the data that you can define there are actually replacement of > some values you could set in the settings tag > (and that are still documented there), or just default values to gain one > or 2 attribute declaration in the <cache> tag > itself.
I introduced cacheDefaults in beta 1 (well, called cache but with the same purpose) to avoid cluttering the settings element with too much attributes related to cache. I think this is more scalable (in terms of cache related features). So my intention was to deprecate the cache related settings attributes on the settings element to get them only in the cacheDefaults in the future. This is cleaner IMO, and 2.0 is a good opportunity to do this kind of change. But if the community feels like it's better to keep cache related attributes in settings element to avoid deprecating attributes I'm ok. > > PS: By the way, I didn't know that defaultCache in settings was only there > for backward compatibility reason. I'm using > it in order to have one cache per group of similar project that I have on > my machine. Pretty usefull! [EMAIL PROTECTED] is not deprecated yet, but I'm suggesting to deprecate it in favor of [EMAIL PROTECTED] which is more explicit IMO (especially because now that you can have multiple cache instances, we have a defaultCacheManager attribute on settings which mimic the defaultResolver attribute, and which can thus be easily confused with defaultCache). Then I'm wondering if we should keep this concept of default basedir for both resolution and repository cache, or if we should force people to configure both separately. This doesn't remove any flexibility and would still allow you to do what you do, but would make people aware of the two kind of caches, and help them consider them separately which would be a good thing IMO. But if we consider most users won't care about separating resolution and repository caches, having a way to configure the base directory for both at once still makes sense. In that case we'd need to choose if we keep it in [EMAIL PROTECTED] or put it in [EMAIL PROTECTED] So, does it make my intent clearer? And do you agree with my opinion, or want to make another proposal? Xavier > > > > Gilles > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
