ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Buck" <rb...@m-Qube.com>
Subject RE: machine local repositories and disconnected development
Date Wed, 31 Jan 2007 13:58:04 GMT
 

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com] 
> Sent: Monday, January 29, 2007 9:40 AM
> To: ivy-user@incubator.apache.org
> Subject: Re: machine local repositories and disconnected development
> 
> On 1/26/07, Robert Buck <rbuck@m-qube.com> wrote:
[...]
> 
> >
> > Because the IVY implementation of a cache violates the single 
> > responsibility principle, its use in this sort of model is 
> compromised 
> > on account of the different classes of data stored in it. 
> Rather than 
> > introducing a private meta-data cache (per workspace) that only has 
> > the dependency information necessary for the resolve and publish 
> > mechanisms, IVY presently throws all these artifacts in with the 
> > published and resolved artifacts. The meta data clearly has no 
> > practical value outside of an individual workspace, and 
> this seems to 
> > be a pretty large design flaw.

> I'm not sure to understand what you mean here, but the Ivy 
> cache is not really meant to be shared among several users. 
> But I agree that there are several kind of information in Ivy 
> cache which should be isolated to make it cleaner and more flexible.
> 
> Xavier

All I am saying is that the because the cache fulfills two roles, that
of caching meta data private to a workspace (about the local artifacts),
and storing the local artifacts too, it cannot be used in a "shared"
mode because this would result in corruption of other workspaces.
Consequently, it is for this reason the inverted resolve chain could
never work in practice.

I like the idea of the decorators that was introduced later in this
thread. Then it would seem possible to let the local cache be a purely
workspace concept, containing workspace private information, and the
resolved artifacts could remain in a http caching resolver, satisfying
the targetted goal I was wishing for.

I really like the idea of the decorators. It would really add a lot of
flexibility to IVY, while I might also suggest it might tighten up some
key concepts and details related to IVY, if not also its internal
implementation.

Thanks folks,

-Bob

Mime
View raw message