transitive dependency override

[Shawn Castrianni <Sh...@halliburton.com>]

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?

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

RE: transitive dependency override

[Gilles Scokart <gs...@gmail.com>]

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 <Sh...@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/

Re: transitive dependency override

[Xavier Hanin <xa...@gmail.com>]

On Jan 6, 2008 8:35 AM, Shawn Castrianni <Sh...@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/