ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: machine local repositories and disconnected development
Date Wed, 31 Jan 2007 14:38:57 GMT
On 1/31/07, Robert Buck <rbuck@m-qube.com> wrote:
>
>
> > -----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.
OK, I agree, the two concepts are different and should clearly be
distinguished. I'm currently working on some refactorings, and
hopefully this should ease this distinction in a near future. A first
step in the right direction :-)

>
> 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.
I really like it too, but it won't be straightforward to implement due
to current use of the cache. But it's far from impossible, and would
really improve flexibility and design. Vote for the issue to show your
interest:
https://issues.apache.org/jira/browse/IVY-399

- Xavier

>
> Thanks folks,
>
> -Bob
>

Mime
View raw message