ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Buck" <>
Subject machine local repositories and disconnected development
Date Fri, 26 Jan 2007 13:44:43 GMT
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:

  <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"/>

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

Question: How does one merge a cache and the local repository so that
resolve and publish act out the same file system location?

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?


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.

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


View raw message