ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: machine local repositories and disconnected development
Date Mon, 29 Jan 2007 14:40:03 GMT
On 1/26/07, Robert Buck <> wrote:
> Back in December I asked a series of questions under "newbie: cant get
> local and shared repository to work correctly", referring to the IVY
> documentation for "Configuring default resolver", where I refer to the
> following cited configuration, which has no practical value as it does
> not appear to do what the IVY documentation is implying:
> <ivyconf>
>   <conf defaultResolver="default"/>
>   <include url="${ivy.default.conf.dir}/ivyconf-public.xml"/>
>   <include url="${ivy.default.conf.dir}/ivyconf-shared.xml"/>
>   <include url="${ivy.default.conf.dir}/ivyconf-local.xml"/>
>   <include url="${ivy.default.conf.dir}/ivyconf-main-chain.xml"/>
>   <include url="${ivy.default.conf.dir}/ivyconf-default-chain.xml"/>
> </ivyconf>
> Getting back to that only now...
> It would seem to me IVY has three practical value areas: (a)
> intra-project dependencies, (b) external dependencies, and (c) caching.
> Having used IVY for two months now, there are a number of issues that
> arise due to how IVY is implemented.
> Regarding intra-project dependencies and caching, one ends up with at
> least three duplicate copies of the built artifacts: one in the build
> output directory, one copy in the local repository as a result of the
> publish action, and one copy in the cache resulting from a resolve by a
> depending project (not to mention the artifact ultimately published to a
> public repository). Having at least three copies for each artifact is
> completely unnecessary, for large projects will result in 10's of
> Gigabytes of unnecessary disk utilization, will slow down builds
> significantly.
> Question: How does one merge a cache and the local repository so that
> resolve and publish act out the same file system location?
You can use useOrigin="true" so that your artifacts are not copied to the cache.
> Regarding external dependencies and caching, what is implied in the
> cited documentation is that shared is, well, shared between several
> workspaces. What is not documented is how to achieve a shared
> repository. Specifically, in the email archives people have already
> asked about how to define a machine-local shared repository that is
> "shared" by all workspaces on the local machine, that is NOT published
> to by default. What has not been answered to other people is the HOW.
> Responders have stated that you replicate by some undefined process the
> public repository to the shared repository. What I want to know is the
> HOW. The value of a shared repository is obvious: once the artifacts are
> replicated from the public repository, a developer may work in any
> workspace completely disconnected. However, the shared repository MUST
> NOT be polluted with any workspace specific artifacts.
> Question: What out of the box IVY tooling allows a copy of an artifact
> to be duplicated into the "shared" repository?
See Gilles answer and mine in other e-mail.

> Rants:
> An initial thought (given the current implementation of IVY) was that it
> would have been nice to create a graph such as:
> Public <- Cache(Shared) <- Local
> Where Public is an HTTP based repository, Cache is where the resolved
> artifacts from the public repository go, and Local where the workspace
> artifacts are published to and resolved from.
This one interesting point of view, but Ivy has to be flexible, and
will never hard code this kind of graph. 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).

But the idea is interesting, it could be worth thinking of a way for
Ivy to deal with a cache in a more flexible way. Maybe this should go
in the section "requirements for a 2.0" on the wiki, since the change
seems to be too important for the 1.x stream.

> 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.

> -Bob

View raw message