ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: copying a complete dependency hierarchy
Date Sat, 25 Oct 2008 22:13:10 GMT
I will look into your response, but to answer your question:

I am building both native code and java code with IVY.  Therefore, I am segregating my modules
with configurations representing the platforms we support: win32, win64, linux32, linux64,
and solaris.  The windows .dll's would be in the windows configs, linux .so's would be in
the linux configs, etc.  This allows someone working on the linux32 platform to only have
to download linux32 dependencies saving time and disk space.  No point in downloading dll's
if you are on unix.  Then the installer module at the top of the ivy hierarchy would specify
* for the configurations during resolve and be able to produce an installer for any platform
from the same machine.

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