You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/01/03 13:58:57 UTC
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/
RE: flexible cache management (IVY-399)
Posted by Gilles Scokart <gs...@gmail.com>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: jeudi 3 janvier 2008 18:00
> To: Ant Developers List
> Subject: Re: flexible cache management (IVY-399)
>
> On Jan 3, 2008 3:52 PM, Nascif Abousalh-Neto <Na...@sas.com>
> 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?
>
+1 for lockStrategy
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: flexible cache management (IVY-399)
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 3, 2008 3:52 PM, Nascif Abousalh-Neto <Na...@sas.com>
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: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
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: flexible cache management (IVY-399)
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
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
RE: flexible cache management (IVY-399)
Posted by Gilles Scokart <gs...@gmail.com>.
+1
Gilles
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: vendredi 4 janvier 2008 14:56
> To: Ant Developers List
> Subject: Re: flexible cache management (IVY-399)
>
> After more thoughts and while starting documenting the new cache management,
> I think I have a better alternative to my last proposition:
> - put any defaults related to repository cache managers in the caches
> element. This include the default cache manager to use, the default basedir
> (for repository cache only), default ivy and artifact pattern and default
> lock strategy
> - keep the defaultCache in settings element, and add a resolutionCacheDir
> attribute
> - deprecate cacheIvyPattern and cacheArtifactPattern on settings element in
> favor of ivyPattern and artifactPattern on caches element
> - remove the cacheDefaults element
>
> Here is how a setup would look like:
> <ivysettings>
> <settings defaultCache="path/to/mycache"
> resolutionCacheDir="path/to/resolution/cache/dir" />
> <caches
> default="mycache2"
> basedir="path/to/default/repository/cache/dir"
> ivyPattern="[module]/ivys/ivy-[revision].xml"
> artifactPattern="[module]/[type]s/[artifact]-[revision].[ext]"
> lockStrategy="artifact-lock" >
> <cache name="mycache"
> basedir="mycache"
> ivyPattern="[module]/ivy-[revision].xml"
> artifactPattern="[module]/[artifact]-[revision].[ext]"
> lockStrategy="no-lock"
> />
> <cache name="mycache2" />
> </caches>
> <resolvers>
> <filesystem name="A">
> <ivy
> pattern="${shared}/[organisation]/[module]/ivys/ivy-[revision].xml"/>
> <artifact
> pattern="${shared}/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
> </filesystem>
> <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>
> </resolvers>
> </ivysettings>
>
> I think this is both closer to how some other settings work (like statuses
> element which allow to define the default status) and to how cache was
> defined in 1.x (keeping defaultCache which was used by many users, and will
> still be as long as you don't want to distinguish the two kinds of caches).
>
> So, does it sound like a good solution? Do you guys have other propositions?
>
> 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
Re: flexible cache management (IVY-399)
Posted by Xavier Hanin <xa...@gmail.com>.
After more thoughts and while starting documenting the new cache management,
I think I have a better alternative to my last proposition:
- put any defaults related to repository cache managers in the caches
element. This include the default cache manager to use, the default basedir
(for repository cache only), default ivy and artifact pattern and default
lock strategy
- keep the defaultCache in settings element, and add a resolutionCacheDir
attribute
- deprecate cacheIvyPattern and cacheArtifactPattern on settings element in
favor of ivyPattern and artifactPattern on caches element
- remove the cacheDefaults element
Here is how a setup would look like:
<ivysettings>
<settings defaultCache="path/to/mycache"
resolutionCacheDir="path/to/resolution/cache/dir" />
<caches
default="mycache2"
basedir="path/to/default/repository/cache/dir"
ivyPattern="[module]/ivys/ivy-[revision].xml"
artifactPattern="[module]/[type]s/[artifact]-[revision].[ext]"
lockStrategy="artifact-lock" >
<cache name="mycache"
basedir="mycache"
ivyPattern="[module]/ivy-[revision].xml"
artifactPattern="[module]/[artifact]-[revision].[ext]"
lockStrategy="no-lock"
/>
<cache name="mycache2" />
</caches>
<resolvers>
<filesystem name="A">
<ivy
pattern="${shared}/[organisation]/[module]/ivys/ivy-[revision].xml"/>
<artifact
pattern="${shared}/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
</filesystem>
<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>
</resolvers>
</ivysettings>
I think this is both closer to how some other settings work (like statuses
element which allow to define the default status) and to how cache was
defined in 1.x (keeping defaultCache which was used by many users, and will
still be as long as you don't want to distinguish the two kinds of caches).
So, does it sound like a good solution? Do you guys have other propositions?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: flexible cache management (IVY-399)
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 3, 2008 3:29 PM, Gilles Scokart <gs...@gmail.com> wrote:
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > 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!
settings[@defaultCache] is not deprecated yet, but I'm suggesting to
deprecate it in favor of cacheDefaults[@defaultBasedir] 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 settings[@defaultCache] or put it in
cacheDefaults[@defaultBasedir]
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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: flexible cache management (IVY-399)
Posted by Gilles Scokart <gs...@gmail.com>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> 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.
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!
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org