ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman" <mgit...@gmail.com>
Subject Re: copying a complete dependency hierarchy
Date Sat, 25 Oct 2008 16:29:00 GMT
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:
http://ant.apache.org/ivy/history/trunk/bestpractices.html

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

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="2.3.59.0" />

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

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

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