I like the hints syntax under dependencies. (Even I'm not sure hints is the right word).
I agree with Jim. We must have the possibility to centraly manage your 'hints'. Typically in a multi-module product, the 'hints' will be a global charachteristic of the product, and only occasionaly something specific to a module. So, I think that allowing to include a file like we can include a file for the configurations would be a good solution. Like Xavier, I'm not in favor of adding this to the settings. However, when published, the included files must be in-lined so that the published files are self-containing. Finally, I'm currious to see how the new feature will impact the build traces and the dependency report. Gilles On 24/03/2008, 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. 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/ > -- Gilles Scokart
