ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman" <>
Subject Re: copying a complete dependency hierarchy
Date Sat, 25 Oct 2008 22:04:05 GMT
Ah, I had been assuming that you were creating a new Ivy repository on every
ivy:install, not that you were installing to an existing repository. Sorry
for my confusion.

So let me (as a member of the community) attempt *an *answer to your
question, even if it's not the *best *answer: "How can I get all
configurations of all modules copied over?" One approach would be to specify
in every one of the ivy.xml files for your projects a configuration that
extends a * wildcard for all other configurations. See:

Then for each in-house dependency in each ivy.xml file, wherever the conf
attribute is specified, add a semicolon and specify that your "everything"
conf depends on everything in that dependency:


You may be able to get around having to specify this every time by setting
the defaultconfmapping attribute of the configurations element. See:

Also, on the dependency doc page cited above, there are some examples of the
use of defaultconfmapping.

Anyway, this begs the question, why would you want to copy over all
configurations of all dependency modules? If the module for your WAR project
that you're releasing depends on one implementation of one of your JAR
projects, why do you care that it has at its disposal all other
implementations of that JAR?

On Sat, Oct 25, 2008 at 10:36 AM, Shawn Castrianni <> wrote:

> There are many ways to use Ivy and I may not be following best practices,
> but I think my method fits with the way my company works better.  We have
> two repositories, daily and releases.  daily contains the continuous and
> nightly builds while releases contains the released versions of all the
> modules.  The daily repository is cleaned of any builds older than 1 week
> while the releases repo is never cleaned.  This make it easy to determine
> what can be deleted to save disk space and what should not.  I have a chain
> resolver that firsts looks for a user's local repo, then the daily, and then
> the releases.  This would allow a patch release to only include a small
> portion of the modules that was originally released.  The modules that are
> part of the patch would be built and stored in the daily repo, while
> everything else would come from the releases repo.
> When I say "copy a complete dependency hierarchy", I am not saying to copy
> all versions of all configurations of all modules, which would be a complete
> copy.  I could do that with cp -r.  I only want the released versions of the
> modules, so it is a selective copy.  Therefore, it is not unmaintainable.
>  After all, we need to keep our release builds somewhere.  Yes, we do have
> tags in the source code so we could reproduce them if need be, but it is
> more efficient to keep the release builds of everything to use as
> dependencies for patches as described above.
> ---
> Shawn Castrianni

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message