ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Crahen" <eric.crahen.li...@gmail.com>
Subject Re: machine local repositories and disconnected development
Date Mon, 29 Jan 2007 15:55:43 GMT
https://issues.apache.org/jira/browse/IVY-399

I think both caching issues could be handled through the same decorator
approach

On 1/29/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
>
> On 1/29/07, Eric Crahen <eric.crahen.lists@gmail.com> wrote:
> > On 1/29/07, Xavier Hanin <xavier.hanin@gmail.com> 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)
>
> Very interesting idea, indeed. With enough syntactic sugar, it could
> even be backward compatible, really interesting. One thing to keep in
> mind is to isolate the two parts of the cache: what is cached from
> dependency resolvers (basically module descriptors and artifacts) and
> what is cached for reusing latest resolve or for a deliver (basically
> what lays at the root of the cache in current implementation). This is
> worth an issue in JIRA, could you create it?
>
> - Xavier
>
> >
> > --
> >
> > - Eric
> >
> >
>



-- 

- Eric

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message