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 Sat, 25 Oct 2008 17:36:01 GMT
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

-----Original Message-----
From: Mitch Gitman []
Sent: Saturday, October 25, 2008 11:29 AM
Subject: Re: copying a complete dependency hierarchy

Shawn, at the risk of not addressing your immediate question, I would take a
step back and ask whether you're really doing the right thing by doing an
ivy:install on a release. What an ivy:install gives you is a whole other Ivy
repository. Every time you do another install, you wind up with another
enterprise repository. Not only does that verge on the unmaintainable, but
you would probably find that the different repositories don't differ from
each other by much.

I believe the better way to lock down the dependencies on a release is to do
so with the versions themselves, in combination with the branching provided
by a version control system. Look at the "Dealing with integration versions"
section of the "Best Practices" page:

That page presents two ways of dealing with ever-changing in-house

You could express integration dependencies using the changing attribute,
much like Maven snapshots:
    <dependency org="exemplar" name="configuration" rev="2.3"
changing="true" />

Or you could express integration dependencies by giving each one its own
integration version:
    <dependency org="exemplar" name="configuration" rev="2.3.+" />

Once you're ready to do a release, you could create a release branch in your
version control system, like Subversion. At this point, you would establish
your concrete dependencies.

For changing integration versions, this might look like:
    <dependency org="exemplar" name="configuration" rev="2.3.0" />

For integration versions that each get their own version, this might look
like (where 59 is the arbitrary build you end up using):
    <dependency org="exemplar" name="configuration" rev="" />

Note in each case that the depth of the version numbers extends one level.
From 2.3 to 2.3.0; from 2.3.+

One complication of this approach is that you wind up having to branch
recursively down the dependency tree through all your in-house projects that
constitute a release.

On Fri, Oct 24, 2008 at 5:43 PM, Shawn Castrianni <> wrote:

> After we release, I would like to copy the entire dependency hierarchy (all
> configurations of all modules) for the version that we actually released.  I
> tried using the install task by changing to the highest module in the
> hierarchy and ran the install task specifying the version of that highest
> level module that we released.    This almost worked in that the
> corresponding transitive dependencies were copied to my destination.
>  However, my top level module only has a subset of the configurations such
> that it only grabs the corresponding subset of configurations for all
> transitive modules.  How can I get all configurations of all modules copied
> over?
> ---
> Shawn Castrianni
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
View raw message