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
