Hi Mitch (et al), thanks for the answer. Let me give you some more info:
Mitch Gitman wrote: > I would recommend using ivy:cachepath over ivy:retrieve. With retrieve, > you're doing an extra copy of the dependencies, which leaves you > vulnerable to the files getting out of sync. Without seeing your Ivy > settings, I can't say why things are slower on cachepath or retrieve. > If I understand correctly, you're encountering this 11-second cost > every time you do a compile. If that's the case, it would mean that Ivy > is not trusting your cache at all and forcing a download every time. No, that's not the case, ivy does not trigger a download from the remote repositories, but takes that much extra time simply to resolve the dependencies from the cache. A download takes AGES (since the main remote repository is on a slow connection). Maybe this is indeed a problem that only occurs on my machine, since on other machines the resolve is quicker, maybe about 2-3 times. > Regarding your other question, I would say it's generally regarded as a > bad practice to place your confs and dependencies for the build in the > same ivy.xml as the confs and dependencies for the current project. > What you'll find is that the confs for the build almost never change > across projects while the project confs do change. Even if you use > standard project confs (core, compile, etc.), you'll find that the > build dependencies never change from project to project while the > project-proper dependencies do. > > The two alternatives I've seen out there to putting build dependencies > in the ivy.xml are: > * Give the build its own ivy.xml. Is there any example for this? > * Define each build dependency inline in the ivy:resolve as it's > needed. Do inline="true". Also not a bad idea. Regards, -- Ole Langbehn, Breitenfelder Str. 13c, 20251 Hamburg, +4917649802788
signature.asc
Description: This is a digitally signed message part.
