ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject RE: transitive dependency override
Date Mon, 07 Jan 2008 13:22:15 GMT
An other solution is to use 2 repository.  In one, you publish by putting the fixed version
number.  In the second, you
publish ivy files that have all its dependencies using latest.integration (or an other latest).

Depending on which repository you are using, you will have one or the other behaviour. 

Gilles

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: lundi 7 janvier 2008 14:10
> To: ivy-user@incubator.apache.org
> Subject: Re: transitive dependency override
> 
> On Jan 6, 2008 8:35 AM, Shawn Castrianni <Shawn.Castrianni@halliburton.com>
> wrote:
> 
> > 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
> solution...
> 
> One thing which could be slightly better is to use properties to reference
> the revision (something like ${b.to.a.revision}) 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 :-)).
> 
> HTH,
> 
> Xavier
> 
> 
> >
> > ---
> > 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
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/


Mime
View raw message