ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: transitive dependency override
Date Mon, 07 Jan 2008 13:10:14 GMT
On Jan 6, 2008 8:35 AM, Shawn Castrianni <>

> Let's consider the situation of C depends on B which depends on A.  In
> other words, ivy module C has a direct dependency on B and an indirect or
> transitive dependency on A.  My current build system which does NOT use ivy
> will always get the latest revision of all dependencies whether direct or
> indirect(transitive).  Obviously, this is bad since if A has recently been
> built and is newer than B, getting the latest of both A and B will result in
> an incompatibility since B was never built with this latest A and may not
> work.  I have always wanted my current build system to get the latest
> revision of the direct dependencies and the corresponding compatible
> revisions of its indirect(transitive) dependencies.  This is the first thing
> I tested with Ivy and it works exactly the way I hoped by default out of the
> box.  My question is can this be overriden on a developer's machine such
> that all latest revisions of all dependencies are retrieved?  Ignore the
> fact that this may be a bad idea in general, but I would like the
> flexibility just in case I need it.
> The developer could modify his copy of the ivy.xml file, but that only
> allows him to control the revision for the direct dependencies because that
> is all that is listed in that ivy.xml file.  Would he have to add in
> indirect(transitive) dependencies into his ivy.xml as direct dependencies
> to give him the ability to specify latest.integration?  This would result
> in a conflict resolution which, by default, would take the latest revision?
>  Seems like it might work, but is this the best way to do this?

Yes, this will work, but it alters the dependency meta information, which is
never a good idea IMHO. The problem is that there is no other good

One thing which could be slightly better is to use properties to reference
the revision (something like ${}) even in the published Ivy
file (in the repository). Then you can give default values to these
properties based on when B has been published, and override these values
when you need. The problem of this approach is that it also alters the
dependency metadata (in a different way, since you alter only revisions and
not the dependency set), and it's more complex to implement.

Yet another solution is to implement your own dependency resolver delegating
to a regular one, and in this resolver check a property when resolving the
dependency from B to A. If the property is set, ignore the revision asked
and use latest.integration instead. This might be the best solution (out of
the bad ones I see here :-)).



> ---
> 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.

Xavier Hanin - Independent Java Consultant

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