ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: copying a complete dependency hierarchy
Date Sun, 02 Nov 2008 23:17:09 GMT
I was thinking about this some more and the install task doesn't mention anything about configurations.
 How would the install task know to use this new everything configuration.  In other words,
I see that the first step in the install is to resolve dependencies, but what configurations
does it use for the resolve part?  I would think there should be a conf attribute for install
that would get passed to the resolve part of install.  Since there is no configuration mentioned
for install, I would think that it would always copy the entire module with all configurations?

Shawn Castrianni

-----Original Message-----
From: Mitch Gitman []
Sent: Saturday, October 25, 2008 5:04 PM
Subject: Re: copying a complete dependency hierarchy

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
View raw message