[
https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532067
]
[EMAIL PROTECTED] edited comment on IVY-399 at 10/3/07 5:03 AM:
----------------------------------------------------------
We ran into another issue recently dealing with an all too common case of cache
corruption. Folks, IVY-399 is the solution to many woes; please, if you do
anything in the 2.0 timeframe, get this one fixed. This is clearly the most
popular issue to be fixed as indicated by your users; please listen to your
user community on this one, and fix it in 2.0. Please?
was (Author: [EMAIL PROTECTED]):
We ran into another issue recently dealing with an all too common case of
cache corruption. Folks, IVY-399 is the solution to many woes; please, if you
do anything in the 2.0 timeframe, get this one fixed. This is clearly people
the most popular issue to be fixed; please listen to your user community on
this one, and fix it in 2.0. Please?
> 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
>
> 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.
