[
https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Lalevée resolved IVY-399.
---------------------------------
Resolution: Fixed
Closing as it seems a consensus
> Flexible Cache Management
> -------------------------
>
> Key: IVY-399
> URL: https://issues.apache.org/jira/browse/IVY-399
> Project: Ivy
> Issue Type: Improvement
> Environment: ALL
> Reporter: Eric Crahen
> Labels: patch
> Attachments: patch.txt.bz2
>
>
> Creating an issue at Xaviers request for improving the approach to cache
> management
> On 1/29/07, Xavier Hanin <[email protected]> wrote:
> Supporting this kind of graph
> could be interesting, and what makes it difficult for Ivy is that Ivy
> heavily relies on its cache mechanism, which makes it impossible to do
> what you want (i.e. never put anything from your local repository to
> the cache).
> This would be a very powerful feature to add. In 2.0, is there any reason for
> the cache to have to be so baked into everything? In otherwords, why not
> implement every resolver and all of the internal management w/ no caching
> what so ever baked in anywhere? Instead all caching is done in a decorator
> fashion by wrapping a caching resolver around any other resolver? In
> otherwords, the core of Ivy only knows about resolvers, no concept of cache
> exists in the heart of Ivy.
> It seems to me this would be much more flexible, and it would still be very
> possible to provide the syntactic sugar to make it very simple and even
> seemless to configure these wrappers by default. At the same time, people who
> will use the flexibility have the power to set up chains that might go
> something like.
> (logical chain)
> localresolver
> cacheresolver
> httpresolver url="..."
> cacheresolver
> httpresolver url="..."
> There is no longer any need to have things like useLocal flags. Its already
> expressed that the local resolver is not cached because its just not wrapped
> in a caching resolver.
> I think this idiom should be applied to both artifact and metadata resolution.
> One cool thing about this, is that in this way, since all caching is simply a
> type of resolver we'd provide people who don't like the particular method we
> use to perform caching in the resolver we provide are free to provide their
> own. This would address lots of the issues that have been raised about
> caching, consistency, doing anything remotely fancy with local resolvers -
> right now its very hard to address any of that because caching is not very
> plugable as it stands.
> I think the only drawback is that it seems like its harder to configure out
> of the box because most people by default would want to wrap every resolver
> with a cacheresolver - but like I said, this is easily solvable by providing
> some simple syntactic sugar. For instance the simplehttpresolver might be the
> name of an undecorated resolver for power users, and the things named
> httpresolver would simple be an alias for the cacheresolver wrapped around
> the simplehttpresolver (or subclass, whatever is the most sensible choice)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
