Nascif, You're not the first one to ask for this, Shawn already expressed the same need. But I'm not personnally in favor of this: I prefer to keep this in the Ivy file to keep dependency data in the repository and not in the settings. My proposition would rather to implement an inheritance mechanism as maven provides: All you ivy files could inherit from a central ivy file, which would define the overrides. In this case we would easily be able to publish a self contained ivy file, to ease later parsing of information. Would this be enough, or do you really see an added value in supporting this in settings files?
BTW, please note that what I've introduced here is for overriding information when there is no conflict. To deal with conflicts, I encourage using the existing conflicts sections in Ivy files (or in the settings). The new override mechanism works differently, it makes all dependees which themselves depend on the overriden dependency behave exactly as if they had declared a dependency on the overriden version. So this won't appear as a conflict in dependendees. If several modules make use of this feature in the same set of dependencies, then Ivy will have to deal with that using the conflict manager, exactly as if the dependency declared where the overriden one. Xavier On Mon, Mar 24, 2008 at 8:07 PM, Nascif Abousalh-Neto < [EMAIL PROTECTED]> wrote: > To elaborate on Jim's point, it is important to consider mechanisms that > allow for centralized management of this new feature. > > I can see how this feature would be used to override the dependency of > commonly used jars. For companies with hundreds of projects using those > jars, having a single place to manage overrides would be immensely valuable. > > Having a similar session on the ivy settings files (that you could > customize with variables) providing default values that the ivy-module could > refine would be a way. > > /Nascif > > > -----Original Message----- > From: Jim Adams [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 2:48 PM > To: [email protected] > Subject: RE: specify versions separate from dependencies > > 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. 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. > > > -----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/ > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
