On 1/26/07, Robert Buck <[EMAIL PROTECTED]> 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. Xavier
-Bob
