On Mon, 24 Mar 2008 15:55:17 -0400 Jim Adams <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Monday, March 24, 2008 3:43 PM > > To: [email protected] > > Subject: Re: specify versions separate from dependencies > > > > On Mon, 24 Mar 2008 14:48:11 -0400 > > Jim Adams <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > Sent: Monday, March 24, 2008 2:31 PM > > > > To: [email protected] > > > > 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 > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Wed, 27 Feb 2008 14:23:50 +0100 "Xavier Hanin" > > > > > <[EMAIL PROTECTED]> 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/
signature.asc
Description: PGP signature
