RE: copying a complete dependency hierarchy

[Shawn Castrianni <Sh...@halliburton.com>]

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 [mailto:mgitman@gmail.com]
Sent: Saturday, October 25, 2008 5:04 PM
To: ivy-user@ant.apache.org
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:
http://ant.apache.org/ivy/history/trunk/ivyfile/conf.html

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:
;everything->*

See:
http://ant.apache.org/ivy/history/trunk/ivyfile/dependency.html

You may be able to get around having to specify this every time by setting
the defaultconfmapping attribute of the configurations element. See:
http://ant.apache.org/ivy/history/trunk/ivyfile/configurations.html

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 <
Shawn.Castrianni@halliburton.com> 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
>
>