On Mon, Mar 24, 2008 at 8:29 PM, Harald Braumann <[EMAIL PROTECTED]> wrote:
> 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.
This is already implemented, and is not used for the same purpose. I was
just stating all the features Ivy implements which deals with transitive
dependencies control.
>
>
> > - 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?
My prototype actually use the first syntax I've given:
<engine-hints>
<mediation>
<override org="yourorg" module=".*1" matcher="regexp"
branch="BRANCH" rev="1.0" />
</mediation>
</engine-hints>
But I don't really like it, I'd prefer the second one I give, but which
require changes for exclude and conflicts/manager, and thus deprecating old
syntax. Therefore I ask for feedback on this from the community.
Xavier
>
>
> > 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
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
