[ https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571060#action_12571060 ]
Gilles Scokart commented on IVY-399: ------------------------------------ I have applied your patch. Can we close this issue or does someone want something more? > 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 > 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. - You can reply to this email to add a comment to the issue online.