On Jan 3, 2008 3:52 PM, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote:
> 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? Xavier > > My US$0.02, > Nascif > > -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > 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: [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/
