ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <ha...@unheit.net>
Subject Re: specify versions separate from dependencies
Date Tue, 25 Mar 2008 16:09:35 GMT
On Mon, 24 Mar 2008 15:55:17 -0400
Jim Adams <Jim.Adams@sas.com> wrote:

> I can't think of any way to set a global default version other than
> properties. 
Well, an ivy file, which has the added advantage that it also can be
published to be used by others.

> This was Xavier's suggestion and it has worked out well.
> But here we are talking about overriding a decision made by a
> dependent jar. I need foo version 2 and bar while bar requires foo
> version 1. This is clearly a conflict but somewhere foo says that
> life is ok and we can live with this inconsistency. The problem comes
> when baz has been including foo and bar for quite some time and
> suddenly needs my jar. What did I just do to him silently?
I don't understand the problem here. You always get this sort of
conflicts with transitive dependencies. But with overrides you now get
the chance to fix them.

harry

> 
> > -----Original Message-----
> > From: Harald Braumann [mailto:harry@unheit.net]
> > Sent: Monday, March 24, 2008 3:43 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: specify versions separate from dependencies
> >
> > On Mon, 24 Mar 2008 14:48:11 -0400
> > Jim Adams <Jim.Adams@sas.com> wrote:
> >
> > > Is there any way to include this from another file? What I am
> > > thinking of is that we have a properties file filled with the
> > > default versions of third party dependencies that our build wants
> > > to use. We have different build tracks, corresponding to
> > > different installable portions of our system, where people may
> > > decide that they want to override the original third party
> > > dependencies.
> > I think property files are not flexible enough. There already was
> > the discussion about some kind of parent file where you can specify
> > your overrides. This could be included in the ivy file.
> >
> > > It seems that this
> > > would be possible with this system. I am concerned that I will
> > > end up with conflicts, however, and not know it nor really
> > > understand the implications of these conflicts.
> > I don't see much difference to "normal" conflicts. If A depends on
> > B and C and both, B and C have overrides on D, than from the point
> > of view of A there are two possible versions for D which would have
> > to be resolved. Just the same as when there where two conflicting
> > normal transitive dependencies on D. With the override mechanism
> > you can now choose the version of D in A's ivy file or in its
> > parent, if that feature will be implemented.
> >
> > harry
> >
> > >
> > > > -----Original Message-----
> > > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > > Sent: Monday, March 24, 2008 2:31 PM
> > > > To: ivy-user@ant.apache.org
> > > > Subject: Re: specify versions separate from dependencies
> > > >
> > > > I've started working on this, and come close to a solution. To
> > > > finalize my work, we need to decide upon the syntax we want to
> > > > use in Ivy files to support transitive dependency override
> > > > mechanism.
> > > >
> > > > After some more thoughts on the feature and how it relates to
> > > > existing Ivy features, I think we now have 3 different ways to
> > > > influence transitive dependencies in an Ivy file:
> > > > - transitive dependency exclusion (IVY-431), introduced in
> > > > 2.0.0-alpha1. This feature relies on an 'exclude' tag directly
> > > > under the 'dependencies' element.
> > > > - setting specific conflict managers for transitive
> > > > dependencies. This relies on a 'conflicts' element and its
> > > > child elements 'manager'.
> > > > - overriding version and/or branch of transitive dependencies.
> > > > In the implementation, I've opened the door to more feature
> > > > than that, by implementing a dependency descriptor mediator
> > > > mechanism. Whenever we load a module descriptor dependency
> > > > descriptors to resolve them, we first ask all the dependers to
> > > > mediate each dependency descriptor. Then we use the mediated
> > > > dependency descriptor to resolve the dependency, instead of the
> > > > original one. For the moment I've only implemented one
> > > > mediator, called override. But we could later imagine other
> > > > kinds of mediation which happens before actual dependency
> > > > resolution. For the moment I've used this syntax for this new
> > > > feature: <engine-hints> <mediation>
> > > >             <override org="yourorg" module=".*1"
> > > > matcher="regexp" branch="BRANCH" rev="1.0" />
> > > >         </mediation>
> > > >     </engine-hints>
> > > > This section is put directly under ivy-module element. What I
> > > > would like to do is group the three kind of transitive
> > > > dependencies hints we can give to the resolve engine in an ivy
> > > > file. I'm still wondering what is the best syntax, and if we
> > > > can afford deprecating the syntax of conflicts and module wide
> > > > exclude. If we agree to deprecate them, here's one idea for the
> > > > new syntax: <ivy-module>
> > > >   <dependencies>
> > > >     <dependency ... />
> > > >     <dependency ... />
> > > >     ...
> > > >     <hints>
> > > >       <exclude org="" module="" matcher="" ... />
> > > >       <conflict org="" module="" matcher="" rev|manager="" />
> > > >       <override org="" module="" matcher="" branch="" rev="" />
> > > >     </hints>
> > > >   </dependencies>
> > > > </ivy-module>
> > > > The conflict tag is similar to the current conflicts/manager
> > > > tag, except that the 'name' attribute is replaced by 'manager'.
> > > > All three kind of hints share the same attribute triple (org -
> > > > module - matcher). The usage of this uple is slightly different
> > > > in exclude, where it also applied to other attributes, such as
> > > > artifact (to name the artifacts to exclude transitively).
> > > >
> > > > Another approach would be to put the hints section directly
> > > > under ivy-module instead of under dependencies (as it's the
> > > > case for conflicts/manager today). I think I prefer the former
> > > > approach I propose.
> > > >
> > > > This is open to discussion, please give your feedback, once 2.0
> > > > will be out we won't be able to go back.
> > > >
> > > > Xavier
> > > >
> > > > On Wed, Feb 27, 2008 at 8:30 PM, Harald Braumann
> > > > <harry@unheit.net> wrote:
> > > >
> > > > > On Wed, 27 Feb 2008 14:23:50 +0100 "Xavier Hanin"
> > > > > <xavier.hanin@gmail.com> wrote:
> > > > >
> > > > > > Could you open an issue about that?
> > > > >
> > > > > Here it is: https://issues.apache.org/jira/browse/IVY-753
> > > > >
> > > > > harry
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Xavier Hanin - Independent Java Consultant
> > > > http://xhab.blogspot.com/ http://ant.apache.org/ivy/
> > > > http://www.xoocode.org/

Mime
View raw message