On Mon, 24 Mar 2008 19:30:49 +0100 "Xavier Hanin" <[EMAIL PROTECTED]> wrote:
> 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. Great. > 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. This would get very complex. Because of just saying, I want foo 1.0, I'd have to check which versions would be actual candidates and then exclude all of them. If something changes down the tree, I'd have to recheck and add additional excludes. > - 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). Sounds like a good and flexible solution. From what I understand, that's what your prototype currently does? > 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 > harry
signature.asc
Description: PGP signature
